Europese aanbesteding Midoffice Suite

Europese aanbesteding Midoffice Suite Alphen aan den Rijn, Delft, Ede, Nieuwegein en Zoetermeer onder aanvoering van EGEM en begeleid door M&I/Argitek Europese aanbesteding 2006-023405 Commercieel vertrouwelijk

Status: Definitief Versie: 1.00 Datum: 16 juni 2006

Europese aanbesteding Midoffice Suite

INHOUDSOPGAVE Leeswijzer .............................................................................................................1 1

2

3

Algemeen.....................................................................................................2 1.1

Inleiding...............................................................................................................2

1.2

Achtergrond en doelstelling ................................................................................3

Procedures ..................................................................................................6 2.1

Algemeen.............................................................................................................6

2.2

Bestek ..................................................................................................................6 2.2.1 Vertrouwelijkheid ....................................................................................6 2.2.2 Intellectueel eigendom .............................................................................6 2.2.3 Voorbehoud..............................................................................................6 2.2.4 Onjuistheden ............................................................................................7

2.3

Offertefase ...........................................................................................................7 2.3.1 Schriftelijke vragen..................................................................................7 2.3.2 Prebid meeting.........................................................................................8 2.3.3 Sluitingsdatum Offertes ...........................................................................8 2.3.4 Openen Offertes .......................................................................................9 2.3.5 Beschikbaarheid Inschrijvers ..................................................................9

2.4

Kwalitatieve selectie............................................................................................9

2.5

Beoordelingsfase .................................................................................................9 2.5.1 Te offreren onderdelen ............................................................................9 2.5.2 Programma van Eisen .............................................................................9 2.5.3 Gunningcriteria en weging ....................................................................10 2.5.4 Proof of Concept....................................................................................11

2.6

Globale planning ...............................................................................................12

2.7

Gunning .............................................................................................................13

2.8

Initiële implementatie........................................................................................13

Algemene voorwaarden aan de Offerte .................................................15 3.1

Contactpersonen ................................................................................................15

3.2

Taal ....................................................................................................................15

3.3

Managementsamenvatting.................................................................................15

3.4

Eisen en vragen..................................................................................................15 3.4.1 Toelichting begrippen............................................................................15 3.4.2 Vorm beantwoording .............................................................................16 3.4.3 Controlelijst eisen..................................................................................17 3.4.4 Controlelijst vragen ...............................................................................17

Commercieel vertrouwelijk


4

5

3.5

Geldigheidsduur ................................................................................................18

3.6

Aanlevering .......................................................................................................19

3.7

Voorbehouden ...................................................................................................19

3.8

Referenties .........................................................................................................19

Criteria voor kwalitatieve selectie..........................................................20 4.1

Combinaties en onderaanneming ......................................................................20

4.2

Eisen aan Inschrijvers........................................................................................20 4.2.1 Concernverklaring.................................................................................20 4.2.2 Gesteldheid ............................................................................................20 4.2.3 Technische bekwaamheid ......................................................................22 4.2.4 Financiële en economische draagkracht ...............................................22 4.2.5 Referenties .............................................................................................23

Programma van Eisen .............................................................................26 5.1

Inleiding.............................................................................................................26 5.1.1 Achtergrond ...........................................................................................26 5.1.2 Frontoffice .............................................................................................30 5.1.3 Klantcontactcentrum..............................................................................33 5.1.4 Broker ....................................................................................................37

5.2

Eisen Midoffice Suite ........................................................................................39

5.3

Vragen Midoffice Suite: frontoffice..................................................................40 5.3.1 Webintake ..............................................................................................40 5.3.2 Vraaggeleiding en product/dienstencatalogus ......................................42 5.3.3 Authenticatie en personalisatie..............................................................43 5.3.4 Zoeken....................................................................................................44 5.3.5 Geo-informatie.......................................................................................45 5.3.6 Elektronische betalen.............................................................................46 5.3.7 Overig ....................................................................................................46

5.4

Vragen Midoffice Suite: klantcontactcentrum ..................................................47 5.4.1 Gegevensmagazijn .................................................................................47 5.4.2 Zakenmagazijn.......................................................................................48 5.4.3 Beperkt workflow management..............................................................50 5.4.4 Beperkt relatiebeheer.............................................................................51 5.4.5 Generieke applicatie..............................................................................53 5.4.6 Beperkt document management .............................................................53 5.4.7 Overig ....................................................................................................56

5.5

Vragen Midoffice Suite: broker en technische architectuur..............................57 5.5.1 Broker ....................................................................................................57 5.5.2 Adapters.................................................................................................58 5.5.3 Technische architectuur.........................................................................63



5.5.4 Overig ....................................................................................................66 5.6

Vragen Midoffice Suite: gebruiksgemak en beheer ..........................................67 5.6.1 Gebruiksgemak ......................................................................................67 5.6.2 Beheer ....................................................................................................68 5.6.3 Managementrapportage ........................................................................69 5.6.4 Integratie................................................................................................70

5.7

Eisen en vragen Initiële implementatie .............................................................72 5.7.1 Inleiding.................................................................................................72 5.7.2 Eisen implementatie...............................................................................77 5.7.3 Vragen implementatie............................................................................77

6

Financiën...................................................................................................82

7

Juridische voorwaarden ..........................................................................87

8

Bijlagen .....................................................................................................88 8.1

EGEM Midoffice Referentiearchitectuur V0.9 .................................................88 Apart bijgevoegd ...............................................................................................88

8.2

Nederlandse Overheid Referentie Architectuur (NORA) V0.8 ........................89 Online beschikbaar............................................................................................89

8.3

Gemeente Alphen aan den Rijn.........................................................................90 8.3.1 Algemene informatie..............................................................................90 8.3.2 Meer- en minderwerk.............................................................................96 8.3.3 Extra’s....................................................................................................97

8.4

Gemeente Delft................................................................................................100 8.4.1 Algemene informatie............................................................................100 8.4.2 Meer- en minderwerk...........................................................................101 8.4.3 Overige informatie...............................................................................101

8.5

Gemeente Ede..................................................................................................103 8.5.1 Algemene informatie............................................................................103

8.6

Gemeente Nieuwegein.....................................................................................104 8.6.1 Algemene informatie............................................................................104 8.6.2 Meer- en minderwerk...........................................................................109

8.7

Gemeente Zoetermeer .....................................................................................110 8.7.1 Algemene informatie............................................................................110 8.7.2 Meer- en minderwerk...........................................................................117 8.7.3 Extra’s..................................................................................................117

8.8

Infrastructuur ...................................................................................................120

8.9

Gemeentelijke applicaties (top-7)....................................................................121

8.10

Applicaties (meerwerk) ...................................................................................122

8.11

Applicaties (overig) .........................................................................................123



8.12

Initiële implementatie: producten....................................................................124 8.12.1 Aanvragen GBA-uittreksel...................................................................128 8.12.2 Aanvragen binnengemeentelijke verhuizing ........................................129 8.12.3 Aanvragen inzameling grofvuil............................................................130 8.12.4 Afspraak maken ...................................................................................134 8.12.5 Aanvragen lichte bouwvergunning (via Digitaal Bouwloket) .............138 8.12.6 Indienen melding openbaar gebied .....................................................139 8.12.7 Indienen generiek bezwaarschrift (inclusief WOZ) .............................140

8.13

Beschrijving Proof of Concept ........................................................................141

8.14

Algemene voorwaarden Proof of Concept ......................................................144

8.15

Controlelijst eisen............................................................................................147

8.16

Controlelijst vragen .........................................................................................149

8.17

Eigen verklaring ..............................................................................................152

8.18

Conceptovereenkomst .....................................................................................153 Apart bijgevoegd .............................................................................................153

8.19

Conformiteitenlijst conceptovereenkomst.......................................................154

8.20

Verklarende woordenlijst ................................................................................158



LEESWIJZER •

Hoofdstuk 1 Hoofdstuk 1 bevat de achtergrond en doelstelling van de aanbesteding.

•

Hoofdstuk 2 Hoofdstuk 2 bevat de procedures van de aanbesteding.

•

Hoofdstuk 3 Hoofdstuk 3 bevat de algemene voorwaarden die aan de Offertes worden gesteld.

•

Hoofdstuk 4 Hoofdstuk 4 bevat de criteria voor de kwalitatieve selectie van de Inschrijvers.

•

Hoofdstuk 5 Hoofdstuk 5 bevat het Programma van Eisen.

•

Hoofdstuk 6 Hoofdstuk 6 bevat de financiële kaders.

•

Hoofdstuk 7 Hoofdstuk 7 bevat de juridische voorwaarden.

•

Hoofdstuk 8 Hoofdstuk 8 bevat de afsluitende bijlagen.


1


1

ALGEMEEN

1.1

Inleiding

Voor u ligt het Bestek in het kader van de openbare Europese aanbesteding voor de selectie van een zogeheten ‘Midoffice Suite’, alsmede de initiële implementatie daarvan. U wordt uitgenodigd om op basis van dit Bestek een Offerte uit te brengen. Begrippen In het onderhavige Bestek worden de volgende begrippen gehanteerd. Voor een uitgebreide toelichting op het begrip ‘Midoffice Suite’, inclusief de betreffende terminologie, wordt u verwezen naar paragraaf 5.1. Bovendien bevat bijlage 8.20 een verklarende woordenlijst. •

Bestek Dit document inclusief alle genoemde bijlagen.

•

Consortium De gezamenlijk aanbestedende gemeenten, te weten: -

Alphen aan den Rijn (ca. 70.000 inwoners) Delft (ca. 95.000 inwoners) Ede (ca. 106.000 inwoners) Nieuwegein (ca. 62.000 inwoners) Zoetermeer (ca. 117.000 inwoners)

Deze gemeenten vertegenwoordigen gezamenlijk dus niet alleen ruim 450.000 inwoners, maar kunnen ook model staan voor de meeste middelgrote gemeenten. •

Midoffice Suite Een Midoffice Suite omvat verschillende functionaliteiten die uiteenvallen in een drietal onderdelen: frontoffice, klantcontactcentrum en broker. Klantcontactcentrum en broker vormen samen het midoffice. De verschillende functionaliteiten die aldus ieder aan één van deze onderdelen worden toegerekend, worden in dit Bestek bovendien ook wel aangeduid als componenten (bijvoorbeeld de ‘component’ webintake in het ‘onderdeel’ frontoffice). NB: de hier genoemde componenten van de Midoffice Suite per onderdeel zijn weliswaar illustratief, maar niet noodzakelijkerwijs uitputtend. -

Frontoffice -

Webintake Vraaggeleiding Product/dienstencatalogus (PDC) Zoeken Authenticatie Personalisatie Elektronisch betalen Geo-informatie (presentatie)


2

Europese aanbesteding Midoffice Suite -

Klantcontactcentrum -

-

Broker -

•

Gegevensmagazijn Zakenmagazijn Generieke applicatie Beperkt workflow management Beperkt document management Beperkt relatiebeheer

Broker Adapters

Inschrijver De leverancier die op basis van de in het Bestek gestelde voorwaarden een Offerte uitbrengt.

•

Initiële implementatiepartner De Inschrijver aan wie de opdracht tot levering van een Midoffice Suite alsmede de Initiële implementatie (inclusief training en opleiding van eindgebruikers) wordt gegund.

•

Initiële implementatie De installatie en basisimplementatie van de Midoffice Suite, alsmede de inrichting van de eerste zeven ‘producten’ (zie bijlage 8.12).

•

Offerte Alle documenten die de Inschrijver aanbiedt ter beantwoording van het gestelde in dit Bestek.

•

First party (1P) First party heeft betrekking op de geoffreerde applicatie(s), functionaliteiten, componenten en dergelijke die worden meegeleverd met de geoffreerde applicatie(s). Als zodanig heeft ‘first party’ per definitie betrekking op applicaties, functionaliteiten, componenten en dergelijke die geleverd worden door de Inschrijver die ze offreert.

•

Third party (3P) Third party heeft betrekking op andere dan de geoffreerde applicatie(s), functionaliteiten, componenten en dergelijke, welke derhalve niet worden meegeleverd met de geoffreerde applicatie(s). Als zodanig heeft ‘third party’ per definitie betrekking op applicaties, functionaliteiten, componenten en dergelijke die niet geleverd worden door de Inschrijver maar door een derde partij. In het algemeen heeft de term ‘third party’ betrekking op applicaties, functionaliteiten, componenten en dergelijke die reeds aanwezig zijn.

1.2

Achtergrond en doelstelling

Burgers en bedrijven verlangen tegenwoordig steeds betere en snellere dienstverlening van lokale overheden. Gemeenten zullen in 2007, in navolging van het actieprogramma Andere Overheid, meer dan de helft van hun publieke dienstverlening via elektronische weg moeten Commercieel vertrouwelijk

3


aanbieden. Deze opgave, gecombineerd met andere doelen op het gebied van onder meer zorg en welzijn, werkgelegenheid en veiligheid vereisen dan ook een grondige modernisering van de gemeentelijke informatievoorziening. Teneinde individuele gemeenten te ondersteunen worden vanuit het Programmabureau EGEM verschillende programma’s en projecten uitgevoerd, zoals de projecten Voorhoedegemeenten en Referentiemodel Midoffice. Dit laatste project heeft betrekking op het ontwerpen van een gemeentelijke architectuur voor elektronische dienstverlening waarbij onderscheid gemaakt wordt tussen een front-, mid- en backoffice. Het onderhavige Bestek is dan ook gedeeltelijk gebaseerd op dit EGEM Referentiemodel Midoffice (zie bijlage 8.1), hoewel dit Bestek een enigszins afwijkende terminologie hanteert. Daarnaast is voor dit Bestek ook gekeken naar de zogeheten Nederlandse Overheid Referentie Architectuur (NORA, zie bijlage 8.2), alsook naar de beoordelingscriteria van het laboratoriumonderzoek van adviesbureau M&I/Argitek, dat deze aanbesteding begeleidt (zie ook www.argitek.nl/research en www.kellerseminar.nl). Het Consortium besteedt, onder aanvoering van EGEM, gezamenlijk een Midoffice Suite aan om (elektronische) dienstverlening aan hun klanten te verbeteren. Eén van de voordelen van samenwerken is dat er een soort ‘community’ ontstaat die onderling kennis en ervaring kan uitwisselen en bovendien zaken als adapters, formulieren, producten procesbeschrijvingen en datamodellen voor de inrichting van gegevens- en zakenmagazijn en dergelijke kan (laten) ontwikkelen en uitwisselen. Om deze voordelen volledig te benutten zal het Consortium na de aanbesteding blijven bestaan, inclusief de coördinerende rol van EGEM daarbij. Midoffice Suite Een Midoffice Suite omvat verschillende functionaliteiten die uiteenvallen in drie onderdelen: frontoffice (FO), klantcontactcentrum (KCC) en broker. • Frontoffice (FO) Het frontoffice (FO) bevat naast webintake functionaliteit (elektronische formulieren) ook functionaliteit op het gebied van authenticatie en autorisatie (bijvoorbeeld middels DigiD), elektronisch betalen (bijvoorbeeld via Ogone), vraaggeleiding (door middel van zogeheten ‘beslisbomen’), een product/diensten catalogus (PDC) en dergelijke. • Klantcontactcentrum (KCC) Het klantcontactcentrum (KCC) omvat, naast een gegevens- en een zakenmagazijn, ook beperkte functionaliteit op het gebied van relatiebeheer (CRM) en workflow- en document management (WfM respectievelijk DMS), waardoor de betreffende omgeving als een soort ‘generieke applicatie’ kan gaan fungeren. • Broker De broker bevat zogeheten Business Process Management (BPM) functionaliteit, alsmede zogeheten ‘adapters’. Het midoffice (MO), dat bestaat uit het klantcontactcentrum (KCC) en de broker, vormt samen met het frontoffice (FO) de Midoffice Suite. Het midoffice omvat daarmee een verzameling functionaliteiten om het geheel van (zowel technische als procesmatige) koppelingen tussen het fronten het backoffice beheersbaar te houden. Aldus vormt het midoffice als het ware een generiek (ont)koppelvlak waarop de verschillende fronten backoffices kunnen worden aangesloten. Commercieel vertrouwelijk

4


Opzet aanbesteding Door middel van deze aanbesteding wordt per gemeente een Inschrijver gecontracteerd die de applicatie(s) levert om in de gewenste functionaliteiten van de Midoffice Suite te voorzien en bovendien als Initiële implementatiepartner de Initiële implementatie uitvoert, inclusief onderhoud voor drie jaar met tweemaal de mogelijkheid tot verlenging met één jaar. De uiteindelijke selectie zou in de tweede helft van 2006 zijn beslag moeten krijgen. Aangezien de gemeenten verenigd in het Consortium een geïntegreerde oplossing willen, is afgezien van een aanbesteding in percelen. Elke gemeente in het Consortium heeft de mogelijkheid om ook na de Initiële implementatie met de geselecteerde Inschrijver door te gaan met het implementeren van producten onder de voorwaarden van de Offerte. De gemeenten verenigd in het Consortium behouden zich echter wel het recht voor om ook (implementatie)werkzaamheden te laten uitvoeren door andere leveranciers. De gemeenten hebben bovendien de intentie om na de Initiële implementatie liefst zoveel mogelijk in eigen beheer producten te kunnen toevoegen (zonder dat daartoe kennis van programmeertalen, html en dergelijke vereist is). Indeling Bestek Hoewel de eisen en wensen van de bij het Consortium aangesloten gemeenten inzake een Midoffice Suite grotendeels overeen komen, vereist ieders specifieke achtergrond andere accenten. In dit Bestek komt dit tot uitdrukking doordat, in aanvulling op het generieke deel, voor elk van de gemeenten een specifieke bijlage is opgenomen (zie bijlagen 8.3 t/m 8.7) met eventuele aanvullingen. Daarnaast bevatten de bijlagen 8.8 t/m 8.11 informatie die met name betrekking heeft op de infrastructuur en reeds aanwezige (3P) applicaties van de gemeenten. Infrastructuur heeft in dit kader vooral betrekking op hardware, databases en platforms zoals Windows, Linux en gelijkwaardige platforms. Gunningtraject Na het beoordelen van de Offertes ontstaat voor iedere gemeente een top-3 van Inschrijvers en zijn er meerdere vervolgtrajecten mogelijk. Allereerst kan een gemeente, indien zij daartoe besluit, de opdracht direct gunnen aan de Inschrijver met de hoogste totaalscore (zie paragraaf 2.5.3). Indien een gemeente echter behoefte heeft aan nadere informatie van de Inschrijvers uit haar top-3, dan worden deze uitgenodigd om door middel van een zogeheten ‘Proof of Concept’ (PoC) hun propositie in een proefopstelling te demonstreren. De mate waarin wordt voldaan aan de deliverables van de Proof of Concept (zie bijlage 8.13) zal worden gewaardeerd, evenals een presentatie voor belanghebbenden binnen de betreffende gemeente(n). Teamleden die bij de uiteindelijke implementatie(s) betrokken zijn, dienen ook bij een eventuele Proof of Concept betrokken te zijn, in een gelijkwaardige rol. Een interview van het geoffreerde team maakt eveneens deel uit van de PoC. Eén en ander wordt uitgebreid toegelicht in paragraaf 2.5.4.


5


2

PROCEDURES

2.1

Algemeen

Voor de onderhavige openbare aanbesteding wordt het zogeheten Besluit Aanbestedingsregels voor Overheidsopdrachten (Staatsblad 2005, 408), hierna te noemen BAO, gevolgd. De volledige tekst van het BAO is te vinden op de website van het Ministerie van Economische Zaken: http://www.minez.nl/content.jsp?objectid=36559. De aanbestedende dienst wordt gevormd door de gezamenlijke gemeenten die deelnemen in het Consortium, onder aanvoering van EGEM, waarbij M&I/Argitek voor vragen rondom de aanbesteding als contactpersoon optreedt: -

Contactpersoon: E-mail:

M. (Michael) Roovers [email protected]

NB: het indienen van de Offertes geschiedt via EGEM (zie paragraaf 2.3.3).

2.2

Bestek

2.2.1 Vertrouwelijkheid De leden van het Consortium, EGEM en de Inschrijver respecteren de intellectuele eigendomsrechten op de gegevens en bescheiden, die zij elkaar in het kader van de aanbestedingsprocedure ter beschikking stellen. Zij zijn verplicht tot geheimhouding van de gegevens en bescheiden, die zij elkaar in het kader van de aanbestedingsprocedure ter beschikking stellen, voor zover deze gegevens en bescheiden niet openbaar zijn. De informatie in het Bestek zal slechts aan medewerkers worden getoond die voor het uitbrengen van de Offerte daarvan kennis moeten nemen. De vertrouwelijkheid zal ook worden bewaard wanneer de Offerte niet tot de totstandkoming van een overeenkomst zal leiden. 2.2.2 Intellectueel eigendom Behoudens uitzonderingen door de wet gesteld mag zonder schriftelijke toestemming van EGEM niets uit dit Bestek worden verveelvoudigd (anders dan voor het doel van dit Bestek) door middel van druk, fotokopie, microfilm, of anderszins. Dit is zowel van toepassing op het geheel als op delen van dit Bestek. 2.2.3 Voorbehoud Uit het Bestek vloeien geen verplichtingen voort voor de gemeenten die bij het Consortium zijn aangesloten, anders dan de verplichting zich aan de aanbestedingsprocedure te houden. De leden van het Consortium behouden zich het recht voor om vanwege politiek/bestuurlijke, financiële en/of inhoudelijke redenen de aanbestedingsprocedure stop te zetten, geheel of gedeeltelijk op te schorten dan wel te beëindigen. De leden van het Consortium behouden zich bovendien het recht voor zich om dezelfde redenen uit de aanbestedingsprocedure c.q. het Commercieel vertrouwelijk

6


Consortium terug te trekken. Inschrijvers hebben geen recht op vergoeding van enigerlei kosten gemaakt in het kader van deze aanbestedingsprocedure (met uitzondering van de PoC). Daarnaast kunnen gemeenten één of meer onderdelen en/of componenten niet of niet direct afnemen. In dat laatste geval heeft een gemeente het recht om de niet afgenomen onderdelen en/of componenten gedurende de contractperiode alsnog tegen de geoffreerde prijzen af te nemen (de zogeheten ‘optie’-regeling). Definitieve gunning van een opdracht zal niet anders plaats kunnen vinden dan na een besluit ter zake door een bij het Consortium aangesloten gemeente. Ook na de gunning zijn er situaties mogelijk waarbij een gemeente gerechtigd is het contract te beëindigen. Indien de Inschrijver tijdens de Initiële implementatie een slechte prestatie levert (een mogelijke aanwijzing hiervoor is dat het opgeleverde resultaat ook na de tweede oplevering niet wordt geaccepteerd), is de betreffende gemeente gerechtigd het contract beëindigen. Daarnaast zijn ook de overige gemeenten uit het Consortium waarvan de Initiële implementatie nog niet heeft plaatsgevonden gerechtigd op basis van die slechte prestatie (individueel of als Consortium) het contract met de leverancier te beëindigen. Afhankelijk van de omstandigheden heeft de beoogde beëindiging betrekking op zowel de geleverde software als op de dienstverlening óf alleen op de dienstverlening. 2.2.4 Onjuistheden Dit Bestek met alle bijbehorende bijlagen is met zorg samengesteld. Mocht u desondanks tegenstrijdigheden en/of onvolkomenheden tegenkomen, dan dient u het Consortium hier onverwijld schriftelijk van op de hoogte te stellen via het in paragraaf 2.1 genoemde E-mail adres.

2.3

Offertefase

2.3.1 Schriftelijke vragen Inschrijvers kunnen uitsluitend schriftelijk vragen stellen met betrekking tot het Bestek, tot uiterlijk 12 juli 2006. Vragen kunnen uitsluitend per E-mail, onder vermelding van Vragen Midoffice Suite Consortium, ref. 2006-023405, worden ingediend via het in paragraaf 2.1 genoemde E-mail adres. Alle vragen worden schriftelijk beantwoord. De vragen en antwoorden zullen geanonimiseerd en gelijktijdig aan alle Inschrijvers per E-mail worden toegezonden. Bij eventuele vragen over de inhoud van het Bestek dient steeds te worden aangegeven: -

Op welk deel van het Bestek de vraag betrekking heeft.

-

Het nummer van de betreffende eis of vraag.

De vragen en antwoorden hebben in beginsel geen invloed op de in het Bestek aangegeven vaste sluitingstermijn voor indiening van de Offertes. Eventuele aanvullingen en correcties op het Bestek door het Consortium, zullen aan alle Inschrijvers per E-mail door middel van een Nota van Inlichtingen kenbaar worden gemaakt.


7


2.3.2 Prebid meeting Indien aantal en aard van de ingediende vragen daartoe aanleiding geven, zal er op 12 juli 2006 van 10:00 uur tot 11:00 uur een zogeheten ‘prebid meeting’ worden georganiseerd. Inschrijvers ontvangen hieromtrent tijdig nader bericht, waarbij tevens de locatie bekend gemaakt wordt. Op de prebid meeting wordt aan de Inschrijvers antwoord gegeven op de vooraf schriftelijk ingediende vragen. Een verslag van deze prebid meeting zal aan iedere Inschrijver worden toegestuurd. Als er geen prebid meeting wordt georganiseerd, zullen de antwoorden op de gestelde vragen schriftelijk en geanonimiseerd aan iedere Inschrijver worden verzonden. 2.3.3 Sluitingsdatum Offertes Met inachtneming van de minimaal voorgeschreven termijn van 40 dagen te rekenen vanaf de datum van verzending van de aankondiging (zoals bedoeld in artikel 38, lid 5 van het BAO) moet de Offerte uiterlijk op 14 augustus 2006 om 12:00 uur door het Consortium ontvangen zijn. Indiening geschiedt bij voorkeur op 14 augustus 2006 tussen 11:00 en 12:00 uur op de volgende locatie: EGEM -

Contactpersoon: Adres:

M. (Mark) van den Broek Wilhelmina van Pruisenweg 104 2595 AN, Den Haag (Nederland)

Bij ontvangst van de Offerte zal een ontvangstbewijs worden afgegeven. NB: om toegang te krijgen tot het betreffende pand, dient een geldig legitimatiebewijs te worden overlegd. U kunt zich melden bij de receptie en vragen naar Mark van den Broek van EGEM. Nota bene -

Indien op bovengenoemde datum / tijdstip geen volledige Offerte is ontvangen, wordt aangenomen dat de betreffende Inschrijver geen Offerte wenst in te dienen en zich heeft teruggetrokken.

-

Per E-mail, telefax of telex ingediende Offertes worden niet geaccepteerd.

-

Het risico van vertraging tijdens de (post)verzending en/of door onjuiste c.q. onvolledige adressering is geheel voor rekening van Inschrijver.

-

Het is de verantwoordelijkheid van de Inschrijver dat de Offerte uiterlijk op bovengenoemde datum/tijdstip op het juiste adres is afgeleverd.

-

Met strafport bezwaarde inzendingen zullen worden geweigerd.

-

Offertes die na de sluitingsdatum worden ingediend, zullen niet meer worden behandeld.

-

Door indiening van een Offerte verklaart de Inschrijver zich akkoord met de procedures en voorwaarden zoals opgenomen in dit Bestek.


8


2.3.4 Openen Offertes Na het verstrijken van de inschrijftermijn worden de Offertes geopend. Van de opening wordt een proces verbaal opgemaakt. De opening is openbaar; de Inschrijvers kunnen aanwezig zijn bij de opening. 2.3.5 Beschikbaarheid Inschrijvers Van de Inschrijvers wordt verwacht dat zij tijdens de aanbestedingsprocedure bereid en in staat zijn om vragen met betrekking tot de Offerte binnen 48 uur te beantwoorden.

2.4

Kwalitatieve selectie

Volgens de openbare procedure vindt de kwalitatieve selectie van Inschrijvers plaats alvorens tot beoordeling van de Offerte over te gaan. In artikel 44 t/m 53 van het BAO staan de criteria vermeld voor de kwalitatieve beoordeling en selectie van Inschrijvers. Deze criteria zijn in dit Bestek nader uitgewerkt. Het niet voldoen aan deze criteria zal leiden tot uitsluiting van de procedure. Ter staving van de bekwaamheid en om de continuïteit van de Inschrijver te beoordelen, dient deze de in hoofdstuk 4 gevraagde informatie aan te leveren.

2.5

Beoordelingsfase

Overeenkomstig artikel 54 van het BAO vindt gunning plaats aan de Inschrijver met de vanuit het oogpunt van het Consortium economisch voordeligste inschrijving. 2.5.1 Te offreren onderdelen Zoals gezegd omvat de Midoffice Suite een aantal onderdelen, te weten een frontoffice (FO) deel, een klantcontactcentrum (KCC) deel en een broker deel. Elk van deze onderdelen omvat verschillende zogeheten componenten. Naar alle waarschijnlijkheid zullen alle gemeenten die in het Consortium vertegenwoordigd zijn (vrijwel) de volledige Midoffice Suite aanbesteden. Alle Inschrijvers dienen dan ook alle onderdelen van de Midoffice Suite te offreren, inclusief de meer-/minderprijs voor als één of meer gemeenten toch besluiten één of meer onderdelen of componenten niet af te nemen. Eén en ander wordt nader toegelicht in hoofdstuk 6. 2.5.2 Programma van Eisen Het Programma van Eisen (PvE) in hoofdstuk 5 bestaat uit een tweetal onderdelen: •

Eisen en vragen Midoffice Suite -

Eisen Midoffice Suite (paragraaf 5.2) Vragen Midoffice Suite: frontoffice (paragraaf 5.3) Vragen Midoffice Suite: klantcontactcentrum inclusief DMS (paragraaf 5.4) Vragen Midoffice Suite: broker en technische architectuur (paragraaf 5.5) Vragen Midoffice Suite: gebruiksgemak en beheer (paragraaf 5.6)


9

Europese aanbesteding Midoffice Suite •

Eisen en vragen Initiële implementatie -

Eisen Initiële implementatie (paragraaf 5.7.2) Vragen Initiële implementatie (paragraaf 5.7.3)

Voor alle onderdelen van het Bestek geldt het volgende: -

Alle geformuleerde eisen gelden als absoluut criterium. Dat wil zeggen dat als aan één of meerdere eisen niet wordt voldaan, de Offerte terzijde gelegd wordt.

-

De vragen zijn verdeeld in vragen met een verschillende weging. De vragen aangeduid met een ster (*) wegen in de beoordeling twee keer zo zwaar als de andere vragen.

2.5.3 Gunningcriteria en weging Nadat de Offertes waarvan de Inschrijvers niet voldoen aan de eisen voor kwalitatieve selectie van hoofdstuk 4 zijn verwijderd, vindt er per gemeente in een viertal rondes een beoordeling van de resterende Offertes plaats: 1 Allereerst worden de Offertes terzijde gelegd die niet voldoen aan alle in het Programma van Eisen geformuleerde eisen of waarin niet alle verplichte onderdelen zijn geoffreerd (zie paragraaf 2.5.1). 2 Daarna worden van de resterende Offertes de antwoorden op de vragen in het Programma van Eisen met dubbele weging, gemarkeerd met een ster (*), beoordeeld. Offertes dienen voor maximaal 15% van deze vragen een onvoldoende te scoren. Wanneer dat niet het geval is, wordt de Offerte terzijde gelegd. 3 Van de resterende Offertes worden alle vragen met enkele weging beoordeeld. 4 Ten slotte wordt uit de kwaliteitsscore q en de prijs p de totaalscore f bepaald en wordt er per gemeente een top-3 vastgesteld. Bepalen kwaliteitscore q Per kwalitatief onderdeel worden alle vraagscores opgeteld tot een onderdeelscore, rekening houdend met de weegfactor (dubbel of enkel) van de gestelde vragen. Deze onderdeelscores worden ten slotte gewogen opgeteld tot een totale kwaliteitsscore q met een range van nul tot en met honderd (conform de wegingen in tabel 1).


10


Onderdelen kwaliteitsscore Weging 1 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over 15 frontoffice V1 t/m V15 2 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over 25 klantcontactcentrum (inclusief document management) V16 t/m V40 3 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over 15 broker en technische architectuur V41 t/m V65 4 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over 15 gebruiksgemak en beheer V66 t/m V79 5 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over 25 Initiële implementatie V80 t/m V90 6 De mate waarin wordt voldaan aan de 5 juridische voorwaarden V100 Totaal 100 Tabel 1: onderdelen kwaliteitsscore Bepalen totaalprijs p De totaalprijs p wordt berekend op basis van de licentiekosten (exclusief kosten voor licenties van operating systemen en databases), de kosten voor het onderhoud en de ondersteuning van de software over vijf jaar, driemaal de kosten voor de fixed-price geoffreerde Initiële implementatie (inclusief onderhoud, ondersteuning en training) en een door het Consortium te maken inschatting van de extra kosten van beheer, hardware, platformen (operating systemen, databases en dergelijke) over vijf jaar en andere exploitatiekosten op basis van de geleverde specificaties. Indien een gemeente besluit een bepaald onderdeel of bepaalde component niet (direct) af te nemen, dan wordt van dit onderdeel de prijs niet meegeteld. Bepalen totaalscore f Op basis van de totale kwaliteitscore q en de totaalprijs p wordt ten slotte volgens de formule f = q – a Í 100 Í (p / pmax) de totaalscore f bepaald, waarbij: -

f = totaalscore q = kwaliteitscore a = 0.3 p = totaalprijs pmax = hoogste totaalprijs van alle overgebleven Offertes

2.5.4 Proof of Concept Indien een gemeente behoefte heeft aan een ‘Proof of Concept’ (PoC) voor de Inschrijvers uit de betreffende top-3, dan zullen de betreffende Inschrijvers worden verzocht hun propositie in een proefopstelling te demonstreren. De ervaring heeft geleerd dat een Proof of Concept vaak verhelderend werkt. De Proof of Concept is echter volledig optioneel; indien een gemeente op basis van de uitgebrachte Offertes tot een afgewogen oordeel kan komen, is de gemeente vrij om desgewenst zonder Proof of Concept te gunnen.


11


Door middel van de PoC wordt beoogd aan te tonen dat met de aangeboden applicatie(s) de genoemde functionaliteiten kunnen worden gerealiseerd. De PoC omvat het verzorgen van een proefinstallatie, inclusief het beschikbaar stellen van de volledige documentatie. Bijlage 8.13 bevat een beschrijving van de Proof of Concept. Hoewel het hier een vrij goede indicatie van een eventuele PoC betreft, is het echter mogelijk dat hieraan bij aanvang nog aanvullende eisen gesteld worden. Inschrijvers dienen te garanderen dat na uitnodiging voor een PoC de aangeboden software binnen zeven kalenderdagen geïnstalleerd kan worden op een door het Consortium aan te geven locatie en dat alle documentatie beschikbaar gesteld kan worden. Vervolgens dient de PoC in drie weken te worden geconfigureerd door de Inschrijvers. Ook wanneer er meerdere gemeenten tot een dergelijke PoC besluiten, zal er één centrale PoC worden gehouden. Dit betekent dat, als één of meer Inschrijvers zich in de top-3 van meer dan één gemeente die behoefte heeft aan een PoC bevinden, elk van deze Inschrijvers slechts één proefopstelling hoeft te realiseren. Eén en ander houdt in dat bij de Proof of Concept tenminste drie Inschrijvers betrokken zullen zijn en mogelijk zelfs meer. Per Inschrijver wordt een vergoeding van 15.000 Euro (inclusief BTW) beschikbaar gesteld voor het uitvoeren van een PoC, met dien verstande dat deze niet zal worden uitgekeerd aan Inschrijvers aan wie door één of meer van de aan het Consortium deelnemende gemeenten een opdracht gegund wordt. De mate waarin wordt voldaan aan de deliverables van de PoC (zie hiervoor bijlage 8.13) zal worden gewaardeerd, evenals een presentatie voor belanghebbenden binnen het Consortium. Geoffreerde teamleden die bij de uiteindelijke implementatie(s) betrokken zijn, dienen ook bij een eventuele PoC betrokken te zijn, in een gelijkwaardige rol. Interviews met de geoffreerde teamleden maken eveneens deel uit van de beoordeling van de PoC. Voor de PoC gelden de algemene voorwaarden in bijlage 8.14. Inschrijver dient zich expliciet akkoord te verklaren met de gestelde voorwaarden. Na het uitvoeren van de PoC zullen de kwalitatieve vragen voor de betreffende leverancier opnieuw worden beoordeeld. Deze score en de beoordeling van de PoC worden op een fiftyfifty basis verwerkt in een nieuwe kwaliteitsscore q. Desgewenst (zie ook paragraaf 2.2.3) wordt de opdracht, bij geen bezwaar, gegund aan de Inschrijver met de hoogste totaalscore f (voor de berekening van de kwaliteitsscore q en de totaalscore f zie paragraaf 2.5.3).

2.6

Globale planning

De globale planning van de het traject is weergegeven in tabel 2. Vanaf 1 september 2006 lopen de tijdpaden dus uiteen voor gemeenten die een Proof of Concept (PoC) willen laten uitvoeren en gemeenten die gunnen op basis van de Offertes. Gemeenten die geen gebruik maken van een PoC kunnen, bij geen bezwaar, vanaf 15 september 2006 de definitieve gunning doen. Gemeenten die wel gebruik maken van een PoC kunnen, bij geen bezwaar, vanaf 1 november 2006 de definitieve gunning doen.


12


16 juni 2006

Aankondiging van de aanbesteding in het Publicatieblad van de EU

12 juli 2006

Sluiting verzoeken om nadere informatie; eventuele prebid meeting

14 augustus 2006

Sluiting inzending; aanvang evaluatie Offertes

1 september 2006

Top-3 per gemeente bekend

15 september 2006 Gunning (indien geen PoC) inclusief 15 kalenderdagen bezwaartermijn Indien er wel sprake is van een PoC, is de planning na 1 september 2006 als volgt: 8 september 2006

Installatie PoC gereed

1 oktober 2006

Configuratie, presentatie en interviews gereed; aanvang evaluatie PoC

1 november 2006

Gunning (indien wel PoC) inclusief 15 kalenderdagen bezwaartermijn Tabel 2: globale planning

2.7

Gunning

Onverkort het hiervoor in paragraaf 2.1 vermelde zal iedere bij het Consortium aangesloten gemeente aan de geselecteerde Inschrijver een brief zenden met daarin de mededeling dat deze gemeente voornemens is aan hem te gunnen en dat vervolgens met hem een overeenkomst wordt gesloten, een en ander onder de opschortende voorwaarde, dat binnen een termijn van 15 dagen na dagtekening van de brief geen (civiel of arbitraal) kort geding tegen deze gunningbeslissing wordt aangespannen. Voor het geval binnen de hiervoor genoemde termijn van 15 dagen een dergelijk kort geding wordt aangespannen, wordt de overeenkomst tevens gesloten onder de opschortende voorwaarde, dat de uitspraak in kort geding inhoudt, dat de gunning niet onrechtmatig is. Gelijktijdig met het bekendmaken van de gunningbeslissing aan degene, met wie de overeenkomst wordt gesloten, worden de afgewezen Inschrijvers van dat besluit in kennis gesteld. Zij ontvangen daarover een brief met een korte motivering van de reden van de afwijzing, de verschillen ten opzichte van de uitgekozen Offerte en de naam van de begunstigde. Door iedere belanghebbende kan voorts nadere informatie worden ingewonnen bij het Consortium, bij een te zijner tijd bekend te maken persoon / personen. Een belanghebbende, die het niet met het gunningbesluit eens is, kan binnen een termijn van 15 dagen na het voornemen tot gunning daartegen een (civiel of arbitraal) kort geding aanspannen. In het belang van een snelle en goede voortgang, wordt men in dat geval dringend verzocht het Consortium tijdig op de hoogte te stellen van het aanwenden van dit rechtsmiddel, bij voorkeur door het opsturen van een kopie van de dagvaarding.

2.8

Initiële implementatie

Wanneer de onderhavige opdracht voor meer dan één van de deelnemende gemeenten aan één en dezelfde Inschrijver wordt gegund, bestaat de mogelijkheid dat deze Inschrijver de Initiële implementaties van de betreffende gemeenten niet gelijktijdig kan uitvoeren. In dat geval zal de fasering van deze Initiële implementaties door het Consortium worden vastgesteld.


13


Inschrijver dient bij elk van de gemeenten die de onderhavige opdracht aan hem gunnen de Initiële implementatie binnen zes maanden te hebben afgerond, gerekend vanaf het moment dat de betreffende gemeente de opdracht tot Initiële implementatie geeft. Dit betekent naar alle waarschijnlijkheid dat de Initiële implementaties deels opeenvolgend en deels parallel zullen plaatsvinden. Elk van de aan het Consortium deelnemende gemeenten heeft het recht om af te zien van de Initiële implementatie, wanneer de Initiële implementatie van die Inschrijver aan wie zij de opdracht gegund heeft, eerder bij een andere gemeente uit het Consortium niet succesvol wordt opgeleverd (een mogelijke aanwijzing hiervoor is dat het opgeleverde resultaat ook na de tweede oplevering niet wordt geaccepteerd).


14


3

ALGEMENE VOORWAARDEN AAN DE OFFERTE

Dit hoofdstuk bevat de algemene voorwaarden waaraan de Offerte dient te voldoen.

3.1

Contactpersonen

Vermeld in de Offerte de contactpersonen (commercieel en technisch) voor het offertetraject, met daarbij per contactpersoon de volgende informatie: -

Naam Functie Organisatieonderdeel waar hij/zij werkzaam is Kantooradres Telefoonnummer Faxnummer E-mail adres Onderdeel van de Offerte waarvoor hij/zij contactpersoon is

3.2

Taal

De Offerte dient volledig in de Nederlandse taal te zijn gesteld.

3.3

Managementsamenvatting

De Offerte dient een managementsamenvatting te bevatten, inclusief prijsoverzicht, van ten hoogste drie pagina’s (exclusief het prijsoverzicht). De beoogde opzet van het prijsoverzicht is weergegeven in hoofdstuk 6.

3.4

Eisen en vragen

Alle in het Bestek opgenomen en genummerde eisen en vragen moeten worden beantwoord, tenzij expliciet anders is vermeld. Voor alle onderdelen van het Bestek geldt het volgende: -

Alle geformuleerde eisen gelden als absoluut criterium. Dat wil zeggen dat als aan één of meerdere eisen niet wordt voldaan, de Offerte terzijde gelegd wordt.

-

De vragen zijn verdeeld in vragen met een verschillende weging. De vragen aangeduid met een ster (*) wegen in de beoordeling twee keer zo zwaar als de andere vragen.

3.4.1 Toelichting begrippen Eisen en vragen zijn uniek geïdentificeerd en worden als volgt onderscheiden: •

Eis (E) Aan een eis moet zonder voorbehoud worden voldaan (absoluut criterium). Indien niet wordt voldaan aan een eis zal de Inschrijver worden uitgesloten van de offerteprocedure.


15


Vraag (V) Met de vragen wordt beoogd uw Offerte af te kunnen zetten tegen concurrerende Offertes (relatief criterium).

Inschrijver moet expliciet op elke eis en vraag ingaan en het betreffende antwoord motiveren; het uitsluitend met ja / nee beantwoorden is niet voldoende. De motivatie van het antwoord op een eis mag bovendien geen voorbehoud bevatten. Eisen en vragen zijn ieder met een unieke codering in dit Bestek opgenomen voor een eenduidige referentie. De betreffende coderingen dienen bij de beantwoording in de Offerte te worden overgenomen. U wordt verzocht bij iedere vraag aan te geven en uitvoerig te documenteren (hiermee wordt tevens bedoeld verwijzen naar meegeleverde documentatie en dus niet naar URL’s): -

In hoeverre de aangeboden applicatie(s) en/of add-ons de genoemde functionaliteiten ‘outof-the-box’ ondersteunen.

-

In hoeverre de aangeboden applicatie(s) en/of add-ons de genoemde functionaliteiten door middel van ontwikkeltools / maatwerk ondersteunen.

-

In welke applicatie(s) en/of add-ons de genoemde functionaliteiten zitten met vermelding van eventueel noodzakelijke add-on modules en hun versienummers.

Indien van toepassing dient iedere vraag voor elk van de aangeboden applicaties en/of addons apart te worden beantwoord. De antwoorden kunnen middels een Proof of Concept (zie ook paragraaf 2.5.4) geverifieerd worden. Toelichtingen of voorbehouden die op meerdere vragen van toepassing zijn, hoeven niet te worden herhaald. In voorkomende gevallen volstaat een verwijzing naar het antwoord op de vraag waar de betreffende toelichting of het betreffende voorbehoud reeds is uitgeschreven. Indien er andere elementaire aspecten zijn die significant bijdragen tot een succesvolle implementatie en die niet in het Bestek staan beschreven, dienen deze in een separate bijlage te worden vermeld. Wanneer bij de beantwoording van een vraag sprake is van add-ons en/of maatwerk bovenop de standaardapplicatie(s), dan wordt ervan uitgegaan dat de kosten hiervan gespecificeerd zijn in de prijsopgave (zie hoofdstuk 6). Het Consortium is zich ervan bewust dat er veel vragen gesteld worden. Als suggestie zouden wij u willen aanraden alle relevante documentatie voor gebruikers, ontwikkelaars, beheerders en dergelijke, alsmede alle overige relevante documentatie bij te voegen en daarnaar zoveel mogelijk te verwijzen (onder vermelding van paragraaf- en/of paginanummers en dergelijke). 3.4.2 Vorm beantwoording De eisen en vragen moeten in de aangegeven volgorde worden behandeld. Bij beantwoording dient de eis of vraag, inclusief het nummer van de eis of vraag, herhaald te worden. Na elke paragraaf (op het tweede niveau: X.X) dient een tabblad te worden opgenomen, voor zover daar eisen en/of vragen zijn verwoord. CV’s dienen in een aparte bijlage bij de Offerte te worden aangeleverd, onder verwijzing naar de vraag op basis waarvan de betreffende CV’s zijn geleverd.


16


Bij beantwoording van een eis dient expliciet te worden vermeld of de Inschrijver eraan voldoet. Daarnaast dient er een toelichting te worden gegeven. Zie in dit kader ook paragraaf 3.4.3 met betrekking tot de controlelijst eisen. 3.4.3 Controlelijst eisen In bijlage 8.15 is een controlelijst opgenomen voor de eisen. In deze lijst dienen Inschrijvers in de kolom ‘Akkoord (ja/nee)’ aan te geven of zij voldoen aan en de betreffende eisen. De kolom ‘Behandeld (ja/nee)’ is een controlemiddel voor de Inschrijvers om te bepalen of alle eisen beantwoord zijn. In de kolom ‘Toelichting’ kan desgewenst een korte toelichting worden opgenomen. Nota bene -

Een toelichting bij een eis mag, overeenkomstig het gestelde in paraaf 3.4.1, geen voorbehoud impliceren.

-

De geformuleerde eisen gelden als absoluut criterium, dat wil zeggen dat als aan één of meerdere eisen niet wordt voldaan, de Offerte terzijde gelegd wordt.

-

Bij verschillen tussen de controlelijst en de individuele beantwoording van de eisen is deze laatste leidend.

3.4.4 Controlelijst vragen In bijlage 8.16 is een controlelijst opgenomen voor de vragen. •

De kolom ‘behandeld (ja/nee)’ is een controlemiddel voor de Inschrijver om te bepalen of alle vragen zijn beantwoord. In de kolom ‘Toelichting’ kan een korte toelichting worden opgenomen:

•

Onder ‘maatwerk (ja/nee)’ dient (indien van toepassing) vermeld te worden of er bij het betreffende antwoord sprake is van maatwerk.

•

Onder ‘add-ons (ja/nee)’ dient (indien van toepassing) vermeld te worden of er bij het betreffende antwoord sprake is van add-ons.

•

Onder ‘toelichting’ kan een eventuele overige toelichting worden opgenomen.

Wanneer bij de beantwoording van een vraag sprake is van add-ons en/of maatwerk bovenop de standaardapplicatie(s), dan wordt ervan uitgegaan dat de kosten hiervan gespecificeerd zijn in de prijsopgave (zie hoofdstuk 6). Nota bene Bij verschillen tussen de controlelijst en de individuele beantwoording van de vragen is deze laatste leidend.


17


3.5

Geldigheidsduur

De Offerte is tenminste geldig tot 1 mei 2007. Tot die datum heeft zij het karakter van een onherroepelijk aanbod.


18


3.6

Aanlevering

De Offerte dient zowel in papieren als in elektronische vorm, in een gesloten pakket, te worden aangeleverd bij EGEM (zie paragraaf 2.3.3) onder vermelding van Midoffice Suite Consortium, ref. 2006-023405. De ingediende exemplaren van de Offerte worden eigendom van het Consortium. Als er een discrepantie bestaat tussen de inhoud van de papieren versie en de elektronische versie, is de papieren versie leidend.

De Offerte in papieren vorm moet aan de volgende eisen voldoen: -

Eén schriftelijk origineel exemplaar, dat enkelzijdig is afgedrukt en per bladzijde geparafeerd, alsmede zes enkelzijdig afgedrukte kopieën.

-

Afgedrukt op A4-formaat met op elke pagina de naam van de Inschrijver en een paginanummering in het formaat ‘X van Y’.

De Offerte in elektronische vorm moet aan de volgende eisen voldoen: -

In tweevoud opgeleverd op twee separate cd-roms.

-

Teksten als Microsoft Word bestand of als PDF-bestand.

-

Spreadsheets als Microsoft Excel bestand.

-

Overige documentatie moet als PDF-bestand worden aangeleverd.

3.7

Voorbehouden

De Offerte zal, behoudens waar dat is gevraagd, geen voorbehoud(en) bevatten ter zake van toekomstige evenementen.

3.8

Referenties

De gemeenten in het Consortium behouden zich het recht voor om, zonder de betreffende Inschrijver daar vooraf van in kennis te stellen, contact op te nemen met referenten om de juistheid van opgegeven referenties te kunnen verifiëren. Referenten dienen daartoe van een bedrijfsnaam, contactpersoon en telefoonnummer vergezeld te zijn. Bij de referenties moet tenminste één referentie zijn, waarbij de goede werking van (delen van) het aangebodene in de praktijk kan worden gedemonstreerd. Eventuele aanschouwing dient zowel tijdens als na het gunningtraject plaats te kunnen hebben. De procedure rond het opgeven van referenties wordt uitgebreid toegelicht in pararaaf 4.2.5.


19


4

CRITERIA VOOR KWALITATIEVE SELECTIE

4.1

Combinaties en onderaanneming

E1

Indien twee of meer Inschrijvers tezamen offreren (een zogeheten ‘Combinatie’) zijn zij hoofdelijk aansprakelijk voor de nakoming van alle uit de overeenkomst of uit de aanbesteding voortvloeiende verplichtingen. De gezamenlijke Inschrijvers zijn verplicht in de Offerte één van hen aan te wijzen om hen in alle opzichten jegens de aanbestedende dienst te vertegenwoordigen en die als opdrachtnemer optreedt in geval van gunning. Van Inschrijvers die als Combinatie aanbieden wordt verwacht dat zij de onderlinge afspraken contractueel vastleggen. Een partij die bij een Offerte als onderaannemer bij een offrerende Inschrijver optreedt, kan niet tevens als hoofdaannemer zelfstandig of als deel van een andere offrerende Combinatie deelnemen in de aanbesteding, tenzij de betreffende partij als onderaannemer uitsluitend software levert.

4.2

Eisen aan Inschrijvers

4.2.1 Concernverklaring E2

Indien bij het offreren door een onderdeel van een concern, de dochter of zuster een beroep doet op de financieel economische ervaring (en/of balansen) van de moeder, dochter en/of zuster maatschappij (een ander van hetzelfde concern), ontvangen wij een getekende concernverklaring van (uitsluitend) de moedermaatschappij, dat deze zich volledig verantwoordelijk stelt voor de uitvoering van de eventuele opdracht en financiële draagkracht van de dochter- of werkmaatschappij (de te leveren zaken en de te verrichten (onderhouds-)werkzaamheden).

E3

Indien bij het offreren door een onderdeel van een concern, deze een beroep doet op de referenties, (financiële) middelen en personeel van moeder-, dochter- en/of zustermaatschappij (een ander van hetzelfde concern), ontvangen wij een getekende verklaring van deze betreffende moeder-, dochter- en/of zustermaatschappij dat zij middelen en personeel ter beschikking zal stellen en dat de offrerende Inschrijver daar feitelijk over zal kunnen beschikken.

E4

U dient een beschrijving van de eigendoms- en bestuurssituatie van de onderneming bij te voegen, bijvoorbeeld een organigram.

4.2.2 Gesteldheid Van deelneming aan deze opdracht wordt uitgesloten iedere Inschrijver: 1 Die in staat van faillissement of van liquidatie verkeert, wiens werkzaamheden zijn gestaakt, jegens wie een surséance van betaling of een akkoord geldt of die in een vergelijkbare toestand verkeert ingevolge een soortgelijke procedure die voorkomt in de op hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie.


20


2 Wiens faillissement of liquidatie is aangevraagd, of tegen wie een procedure van surséance van betaling of akkoord dan wel een andere soortgelijke procedure die voorkomt in de op hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie, aanhangig is gemaakt. 3 Jegens wie een rechtelijke uitspraak met kracht van gewijsde volgens de hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie is gedaan, waarbij een delict is vastgesteld dat in strijd is met zijn beroepsgedragsregels. 4 Die in de uitoefening van zijn beroep een ernstige fout heeft begaan, vastgesteld op elke grond die de aanbestedende diensten aannemelijk kunnen maken. 5 Die niet aan zijn verplichtingen heeft voldaan ten aanzien van de betaling van de sociale verzekeringsbijdragen overeenkomstig de wettelijke bepalingen van het land waar hij gevestigd is of van Nederland. 6 Die niet aan zijn verplichtingen heeft voldaan ten aanzien van de betaling van zijn belastingen overeenkomstig de wettelijke bepalingen van het land waar hij gevestigd is of van Nederland. 7 Die zich in ernstige mate schuldig heeft gemaakt aan valse verklaringen bij het verstrekken van de inlichtingen die overeenkomstig dit hoofdstuk kunnen worden verlangd, of die inlichtingen niet heeft verstrekt. 8 Die bij een gerechtelijk vonnis, dat kracht van gewijsde heeft, wegens deelneming aan een criminele organisatie, omkoping, fraude of het witwassen van geld, is veroordeeld. E5

Ten bewijze dat Inschrijver niet in één van de bovenstaande omstandigheden verkeert, ontvangen wij een eigen verklaring (zie bijlage 8.17) op grond waarvan Inschrijver zelf aangeeft dat gronden voor uitsluiting niet op Inschrijver van toepassing zijn.

E6

Inschrijver dient bij de gunning de volgende bewijsstukken op verzoek te overleggen: -

Voor het vijfde punt van de voorgaande opsomming in deze paragraaf een verklaring van de Belastingdienst, of voor het land van herkomst van de onderneming daarvoor geldende documenten.

-

Voor het zesde punt van de voorgaande opsomming in deze paragraaf een verklaring van de Belastingdienst van de Inschrijver, of voor het land van herkomst van de onderneming daarvoor geldende documenten.

-

Voor de overige punten van de voorgaande opsomming in deze paragraaf een notarisverklaring, waarin het afleggen van verklaring, inhoudende dat aan de bedoelde punten is voldaan, is geconstateerd.

E7

De hierboven genoemde verklaring(en) moeten van een recente datum (niet ouder dan drie maanden, gemeten vanaf de uiterste datum van inlevering van de Offerte) zijn.

E8

Ten bewijze dat een Inschrijver ingeschreven staat in het nationale handelsregister, ontvangen wij een bewijs van inschrijving van de onderneming in het handelsregister, of voor het land van herkomst van de onderneming daarvoor geldende documenten die niet ouder zijn dan drie maanden, gemeten vanaf de uiterste datum van inlevering van de Offerte.


21


E9

Inschrijver beschikt over contactpersonen, leidinggevend en trainingspersoneel, dat de Nederlandse taal machtig is.

E10

Inschrijver garandeert dat er minimaal twee partijen (exclusief de Inschrijver) zijn die de aangeboden applicatie(s) in de fase na Initiële implementatie bij de gemeenten die deelnemen aan het Consortium kunnen implementeren en ondersteunen. Geef aan welke partijen dat zijn.

E11

Inschrijver garandeert de toekomstige ontwikkeling en ondersteuning van de aangeboden Midoffice Suite software en de continuïteit van de software leverancier(s). Geef aan in welke mate de aangeboden applicatie(s) en de bijbehorende ontwikkelaar / leverancier toekomstvast is in termen van producten bedrijfstrategie en de daarbij behorende ontwikkelinspanning voor de komende jaren. Geef per applicatie tevens aan wat de release politiek is (het aantal grote releases, aantal kleine releases, patches en dergelijke) van de applicatieleverancier. NB: deze eis is onafhankelijk van de wijze waarop de softwareleverancier in de aanbieding participeert.

4.2.3 Technische bekwaamheid E12

Inschrijver beschikt over voldoende technische bekwaamheden om de onderhavige opdracht met goed gevolg te kunnen volbrengen. Beschrijf hiertoe de bij de Inschrijver aanwezige kennis en ervaring, alsook het aantal medewerkers (inclusief opleidingsniveau, ervaringsjaren en discipline) waaruit blijkt dat de Inschrijver de onderhavige opdracht met goed gevolg kan volbrengen. Maak hierbij een onderscheid tussen de ontwikkelaars en implementatieadviseurs van de aangeboden applicatie(s) en ga uit van een deels parallelle Initiële implementatie bij vijf gemeenten in zes maanden.

4.2.4 Financiële en economische draagkracht E13

Inschrijver heeft een totale omzet van minimaal twee miljoen Euro (exclusief BTW) in het laatst afgesloten boekjaar. Voor afzonderlijke leden van een Combinatie geldt een minimumeis van één miljoen Euro.

Ter staving van de financiële bekwaamheid en om de continuïteit van de Inschrijver te beoordelen dient deze de informatie aan te leveren zoals vermeld in tabel 3. U dient hiermee aan te tonen dat de financiële draagkracht van uw bedrijf voldoende is om een contract aan te gaan met één of meer gemeenten in het Consortium. De financiële gegevens dienen in Euro’s (exclusief BTW) te worden vermeld. Aan de hand van de jaarrekeningen over de jaren 2003, 2004, 2005 (van de laatste kan ook een voorlopige versie gebruikt worden) dienen de resultaten en balanstotalen (in duizenden Euro's) zoals vermeld in tabel 3 te worden berekend en aldaar te worden ingevuld. Voor een Combinatie geldt dat alle partijen afzonderlijk de betreffende gegevens moeten verstrekken.


22


E14

Inschrijver dient voor de financiële draagkracht te voldoen aan minimaal drie van de vier criteria zoals vermeld in tabel 3. Indien dit minimum niet wordt gehaald zal de Offerte van Inschrijver niet verder in behandeling worden genomen. NB: indien twee of meer partijen als een Combinatie inschrijven, geldt voor elke partij afzonderlijk dezelfde eis.

Omschrijving resultaat / balanstotaal

Kerncijfers jaarrekeningen 2003 2004 2005

Grenswaarden ≥ 1,5 in minimaal twee van de drie jaren ≥ 0,25 in minimaal twee van de drie jaren positief in minimaal twee van de drie jaren ≥ 0,5 miljoen Euro in 2003 en 2004, ≥ 1,0 miljoen Euro in 2005

Current ratio 1 Solvabiliteit 2 Netto winst (EBITDA) 3 Omzet 3 Tabel 3: kerncijfers 1 2 3

Current ratio = vlottende activa / vlottende passiva Solvabiliteit = eigen vermogen / totale activa In duizenden Euro’s, exclusief BTW

4.2.5 Referenties E15

Geef een lijst en beschrijving van vijf referenties bij verschillende organisaties uit de afgelopen drie jaar, waar u fronten/of midoffice (klantcontactcentrumen brokerfunctionaliteit) functionaliteit hebt gerealiseerd. Minimaal drie referenties dienen te zijn uitgevoerd in het Nederlandstalige deel van de Benelux. Alle referenties dienen te worden aangeleverd conform het onderstaande model (zie tabel 4).

E16

Van deze vijf referenties dienen minimaal twee referenties een implementatie door de Inschrijver van de aangeboden frontoffice applicatie(s) te betreffen.

E17

Minimaal één van de vijf referenties dient een implementatie door de Inschrijver van de aangeboden midoffice (klantcontactcentrumen brokerfunctionaliteit) applicatie(s) te betreffen.


23


Organisatie Naam van de organisatie Land en plaats van vestiging van de organisatie Publiek / privaat status (bijv. gemeente of bedrijf) Naam en telefoonnummer van de contactpersoon die in het kader van de referentie kan worden benaderd Opdracht Front- en/of midoffice applicatie(s) Aanvang, duur en omvang van de opdracht Plaats waar de dienstverlening is uitgevoerd. Geef hier tevens aan of de dienst lokaal is geïnstalleerd of als ASP wordt / werd aangeboden. Beschrijving van de diensten van eventuele partners die bij de dienstverlening betrokken zijn / waren. Onderscheid drie typen ‘werkzaamheden’ (levering van standaardsoftware, maatwerk en implementatie) en beschrijf wat door wie is uitgevoerd. Kwalitatief oordeel (korte beschrijving) van de klant op de volgende aspecten van de Inschrijver: betrouwbaarheid, flexibiliteit, snelheid, kwaliteit van het personeel, klantgerichtheid en probleemoplossend vermogen Jaar, duur / termijn en kosten van de implementatie van applicatie(s) van de Inschrijver, inclusief eventuele import, conversie, en/of koppelingen naar andere applicaties. Het aantal gebruikers, verbijzonderd per applicatie van de Inschrijver (fronten/of midoffice), alsmede, indien van toepassing, aantal en type gerealiseerde gemeentelijke producten (bijvoorbeeld ‘aanvraag GBA-uittreksel’). Indicatie van de mate waarin de medewerkers van de betreffende organisatie na de (initiële) implementatie in staat waren om zelfstandig additionele producten (gemeentelijk of anderszins) toe te voegen (indien van toepassing) en zaken als formulieren, processen en dergelijke te creëren, configureren en beheren. Overzicht van de door de Inschrijver gerealiseerde interfaces met externe systemen Overzicht van de door de Inschrijver geleverde diensten op het gebied van implementatie, onderhoud, support en opleiding Overzicht van door de Inschrijver geïmplementeerde modulen, inclusief versienummer Een indicatie van de door de Inschrijver hierbij gerealiseerde omzet, verbijzonderd naar licenties, onderhoud en implementatie met vermelding van de eventueel ingeschakelde (onder)aannemers Tabel 4: model voor aanleveren referenties


24


Het Consortium zal vijf referenties beoordelen. De Inschrijver hoeft dus niet meer referenties op te geven. De referenties zullen worden beoordeeld op de volgende punten: -

Een met een door het Consortium gevraagde (in omvang en diversiteit) vergelijkbare implementatie van de aangeboden frontoffice en/of midoffice (klantcontactcentrumen brokerfunctionaliteit) applicatie(s).

-

Uitgevoerd in de publieke sector, bij voorkeur lokale overheid (gemeenten).

-

Uitgevoerd in het Nederlandstalige deel van de Benelux, bij voorkeur in Nederland.

-

Een implementatie van een combinatie van frontoffice en midoffice (klantcontactcentrumen brokerfunctionaliteit) functionaliteit.

-

Een implementatie van een combinatie van de aangeboden frontoffice applicatie(s) en de aangeboden midoffice (klantcontactcentrumen brokerfunctionaliteit) applicatie(s).

-

De inhoud van de referentie.

E18

De Inschrijver dient bij de beoordeling van de referenties minimaal 50% van het maximum aantal punten te scoren.


25


5

PROGRAMMA VAN EISEN

Middels deze openbare Europese aanbesteding inzake de selectie van een ‘Midoffice Suite’, alsmede de Initiële implementatie daarvan, wordt u uitgenodigd om op basis van dit Bestek een Offerte uit te brengen. De inleidende paragraaf 5.1 is bedoeld om één en ander in een breder kader te plaatsen (met name paragraaf 5.1.1) en het beoogde gebruik van de te offreren applicatie(s) toe te lichten (paragraaf 5.1.2, 5.1.3 en 5.1.4). Hoewel het hier geen uitputtende beschrijving betreft, willen wij u verzoeken om bij beantwoording van de overeenkomstige vragen in dit Bestek ook terdege rekening te houden met dit ‘beoogde gebruik’.

5.1

Inleiding

5.1.1 Achtergrond Elektronische dienstverlening Met de komst van nieuwe verschijningsvormen van informatie- en communicatietechnologie (ICT) zoals het Internet zijn voor publieke organisaties als gemeenten nieuwe mogelijkheden ontstaan, in het bijzonder ten aanzien van meer klantgerichte vormen van bedrijfsvoering en dienstverlening. In de nota Digitale Delta van 1999 wordt zelfs met zoveel woorden gesteld dat de overheid haar dienstverlening aan burgers en bedrijven sterk kan verbeteren door zich te transformeren tot een “elektronische overheid”. Aldus kunnen publieke organisaties onder invloed van ICT worden (her)ingericht en nieuwe elektronische informatie-, communicatieen transactiekanalen ingezet met hun ‘klanten’. Voor gemeenten wordt communicatie via het Internet, met zowel burgers als bedrijven, dan ook steeds belangrijker. Vanuit de landelijke overheid worden hiertoe concrete doelstellingen geformuleerd, zoals het programma ‘Andere overheid’ (65% elektronische dienstverlening in 2007). Ook vanuit de samenleving groeit de vraag naar elektronische dienstverlening, terwijl gemeenten bovendien in toenemende mate een meer klantgerichte benadering kiezen. Eén en ander vereist echter een grondige modernisering van de gemeentelijke informatievoorziening. Vanuit EGEM is het zogeheten Referentiemodel Midoffice ontwikkeld door de gelijknamige werkgroep, waarin voor wat betreft gemeentelijke informatievoorziening onderscheid wordt gemaakt tussen frontoffice, midoffice en backoffice. Front-, back- en midoffice Het frontoffice vormt als zodanig de presentatielaag van een gemeente naar de buitenwereld; alle klantcontacten spelen zich af in het frontoffice. Dergelijke interactie betreft bijvoorbeeld het stellen van vragen, het indienen van klachten en het aanvragen van producten en diensten. Tegenwoordig heeft een gemeente via een veelheid van verschillende kanalen contact met de buitenwereld; niet alleen schriftelijk (post) en telefonisch (callcenter), maar ook elektronisch (website, E-loket) en fysiek (balie). Hierdoor ontstaat de noodzaak tot kanaalsynchronisatie; gemeenten willen klantcontacten over verschillende kanalen ondersteunen en op uniforme wijze doen plaatsvinden, waarbij de verstrekte informatie over elk van de kanalen actueel, correct en inhoudelijk congruent moet zijn. Uitgangspunt voor het frontoffice is de klant; van daaruit worden de verschillende specialistische onderdelen in het backoffice aangesproken.


26


Waar het frontoffice dus de buitenkant van een gemeente vormt waarlangs de interactie met de omgeving zich afspeelt, vormt het backoffice als het ware het hart van de organisatie waar zich, onzichtbaar voor die omgeving, de primaire processen afspelen. Voor het backoffice is het specialisme dan ook het uitgangspunt; van daaruit worden de producten aan de ‘klanten’ (burgers en bedrijven) geleverd. In het ‘traditionele’ backoffice (zie ook ‘dik midoffice’ in de volgende sectie) werkt men bijvoorbeeld aan de afhandeling van een vergunningaanvraag; men stuurt een ontvangstbevestiging, controleert of de aanvraag ontvankelijk is op basis van de vormvereisten, verifieert de verstrekte gegevens en voert een inhoudelijke beoordeling uit. De resulterende beschikking wordt tenslotte naar de aanvrager verstuurd (levering ‘product’). De ontkoppeling van front-, en backoffice door middel van een zogeheten midoffice vormt het uitgangspunt van het EGEM Referentiemodel Midoffice. Hierbij verzorgt het midoffice de verbinding tussen fronten backoffice wanneer deze functioneel, technisch en/of procesmatig van elkaar gescheiden zijn (de zogeheten ‘knip’). Het midoffice bevindt zich dus tussen het fronten het backoffice in; als zodanig is het een verzameling functionaliteiten die zowel de processen als de bijbehorende applicaties en gegevens in het fronten backoffice met elkaar verbindt. Aldus bewerkstelligt het midoffice één generiek (ont)koppelvlak waarlangs alle fronten backoffice systemen kunnen worden ontsloten. In onderstaande figuur 1 is, door middel van een dergelijk midoffice, het aantal benodigde koppelingen tussen N fronten M backoffices (FO’s respectievelijk BO’s): teruggebracht van NÍM tot N+M. Aldus worden niet alleen ongewenste afhankelijkheden uitgebannen, maar kunnen bovendien aanvragen die betrekking hebben op verschillende backoffices vanuit één centraal punt (het midoffice) elektronisch worden afgehandeld. Een aanvraag tot het bouwen van een garage heeft bijvoorbeeld betrekking 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 dan ook centrale sturing van dit ‘digitale loopbriefje’, waartoe het midoffice kan worden ingezet.

Figuur 1: het midoffice als (ont)koppelvlak Dun en dik midoffice Er kan op verschillende wijze invulling gegeven worden aan het midoffice concept. Zo wordt er bijvoorbeeld onderscheid gemaakt tussen zogeheten ‘dunne’ en ‘dikke’ midoffices, waarbij een dun midoffice uitsluitend fungeert als ‘makelaar’ (broker) voor elektronische berichten en als zodanig geen eigen geheugen heeft (stateless), doch hooguit een beperkte set replica’s van backoffice gegevens in een zogeheten gegevensmagazijn. Dit betreft echter slechts zogeheten ‘koude’ data (read-only), zoals een kopie van het GBA voor authenticatie. Een dun midoffice is daarmee vooral een technische voorziening, waarbij via berichtenverkeer aanvragen uit het frontoffice (webintake) via het midoffice naar het backoffice worden geleid via adapters. Commercieel vertrouwelijk

27


Vaak zijn deze voor een dun midoffice benodigde adapters nog slechts beperkt beschikbaar en blijven de backoffice applicaties derhalve relatief gesloten. Dat is een van de redenen dat er op dit moment een onmiskenbare trend naar zogeheten dikke midoffices zichtbaar is. Een dik midoffice krijgt als het ware de functie van een soort vooruitgeschoven backoffice. Hierbij wordt rondom het midoffice een ‘publieksdienst’ gevormd waarnaar voor bepaalde producten (een deel van) de backoffice taken wordt overgeheveld. Een dergelijk dik midoffice heeft wel een eigen geheugen (statefull) en bevat naast koude data in een gegevensmagazijn bovendien zogeheten ‘warme’ data (procesgegevens) in een zogeheten zakenmagazijn. Functionaliteiten en beoogd gebruik In dit Bestek wordt een Midoffice Suite gedefinieerd middels verschillende functionaliteiten die zich in en rondom het midoffice bevinden en uiteenvallen in een drietal delen: frontoffice, klantcontactcentrum en broker. De delen klantcontactcentrum en broker vormen tezamen het zogeheten midoffice (zie figuur 2). Naast webintake functionaliteit (dat wil zeggen functionaliteiten rondom het creëren, beheren, publiceren, invullen en verwerken van elektronische formulieren) bevat het frontoffice deel van de Midoffice Suite ook functionaliteiten die hieraan dienstbaar zijn, zoals vraaggeleiding via zogeheten ‘kennisbomen’, een product/dienstencatalogus (PDC), personalisatie (‘Mijn Gemeente’), authenticatie (bijvoorbeeld via DigiD) en elektronisch betalen (zoals via Ogone). Het klantcontactcentrum deel omvat naast een gegevens- en een zakenmagazijn bovendien functionaliteiten zoals beperkt document management (DMS), beperkt workflow management (WfM) en beperkt relatiebeheer (CRM). Het gaat daarbij in alle drie de gevallen derhalve om relatief beperkte functionaliteit. Aldus kan deze omgeving als een soort ‘generieke applicatie’ gaan fungeren. Het broker deel ten slotte bevat een broker met Business Process Management functionaliteit (BPM), alsmede de zogeheten ‘adapters’.

Figuur 2: functionele componenten Midoffice Suite


28


Deze inleidende paragraaf is bedoeld om één en ander in een breder kader te plaatsen en het beoogde gebruik van de te offreren applicatie(s) toe te lichten. Het vervolg van deze paragraaf is opgebouwd conform de indeling in een frontoffice (paragraaf 5.1.2), klantcontactcentrum (paragraaf 5.1.3) en broker deel (paragraaf 5.1.4) met onder meer de volgende componenten: -

Frontoffice -

-

Klantcontactcentrum -

-

Webintake Vraaggeleiding Product/dienstencatalogus (PDC) Zoeken Authenticatie Personalisatie Elektronisch betalen Geo-informatie (GIS)

Gegevensmagazijn Zakenmagazijn Generieke applicatie Beperkt workflow management (WfM) Beperkt document management (DMS) Beperkt relatiebeheer (CRM)

Broker -

Broker Adapters

De huidige situatie verschilt per deelnemende gemeente en wordt als zodanig toegelicht in de afzonderlijke gemeentespecifieke aanvullingen op dit Bestek (zie bijlagen 8.3 t/m 8.7). De beoogde toekomstige situatie en de rol van de te offreren applicatie(s) daarin worden in de onderhavige paragraaf toegelicht. Eén en ander is dusdanig van opzet, dat dit in principe op elk van de deelnemende gemeenten van toepassing is. Voor zover het beoogde gebruik van de te offreren applicatie(s) bij één of meer gemeenten hier significant van afwijkt, wordt zulks eveneens in de afzonderlijke gemeentespecifieke aanvullingen op dit Bestek toegelicht. Het is uitdrukkelijk de intentie van de gemeenten om de geoffreerde applicatie(s), inclusief webintake, bijvoorbeeld ook door de medewerkers aan de balie en in het callcenter te laten gebruiken voor externe dienstverlening. In dat geval worden de webformulieren door de FO/KCC-medewerkers gebruikt om namens de klant bepaalde producten aan te vragen. De primaire focus op externe dienstverlening beperkt zich dus geenszins tot het gebruik van het webkanaal voor de klant. Hoewel de toelichting primair is gericht op dergelijke externe (elektronische) dienstverlening, dus aan klanten (burgers en bedrijven), hebben gemeenten in het Consortium daarenboven de intentie om dezelfde functionaliteit op termijn eveneens voor interne dienstverlening, dus aan eigen medewerkers, te gaan toepassen. Dit kan bijvoorbeeld betrekking hebben op facilitaire zaken als reserveren van vergaderruimten, beamers en dergelijke, maar bijvoorbeeld ook op declaratieformulieren, het aanmelden van bezoekers en dergelijke.


29


Deze aanbesteding is niet zozeer bedoeld voor de aanschaf van een ‘lege blokkendoos’ waar een Midoffice Suite mee geïmplementeerd kan worden, maar vooral om zoveel mogelijk ‘blokken’ in de vorm van standaardformulier(onderdel)en, een bibliotheek van standaard (sub)processen en (standaard)koppelingen als meerwaarde hierbij aan te schaffen. Ook de uitwisselbaarheid van zelfgebouwde dergelijke ‘blokken’ tussen gemeenten is uitgangspunt van deze aanbesteding. 5.1.2 Frontoffice •

Webintake Eén van de belangrijke onderdelen van de Midoffice Suite wordt gevormd door webintake. Dit betreft functionaliteit voor het ontwikkelen, publiceren, (doen) invullen en verwerken van elektronische formulieren (‘webformulieren’), alsmede voor het beheren ervan. Door middel van dergelijke elektronische formulieren kunnen klanten 24x7 via de gemeentelijke website producten en informatie aanvragen. Het belang van enige mate van geavanceerde functionaliteit ten aanzien van elektronische formulieren is groot. Niet alleen omdat aldus ‘schonere’ informatie wordt verkregen, maar ook omdat met slimme validaties een groot deel van de gegevensinvoer aan de klant kan worden ‘uitbesteed’, hetgeen het aantal nietontvankelijke aanvragen kan reduceren. -

Formulierontwikkeling en -beheer De beoogde toepassing van deze functionaliteit heeft betrekking op het ontwikkelen van elektronische formulieren. Medewerkers van de gemeenten kunnen aldus, zonodig met enige training doch zonder dat kennis van html en dergelijke vereist is, elektronische formulieren ontwerpen. Dit betreft niet alleen de vorm (opmaak, lay-out en dergelijke), maar ook de inhoud (logica, intelligentie en dergelijke) ervan. Het kunnen hergebruiken van (blokken van) formuliervelden, inclusief logica, intelligentie en dergelijke is hierbij een pré. Ook metadatering, versiebeheer en het overerven van bepaalde eigenschappen vallen hieronder. Uiteindelijk hebben de gemeenten in het Consortium ook de intentie om onderling formulier(blokk)en, inclusief intelligentie en logica, uit te wisselen.

-

Intelligentie Onder intelligentie wordt verstaan het dynamisch aanpassen van (de route door) het formulier, al naar gelang hetgeen er wordt ingevuld (‘als dit… dan dat’). Dit kan bijvoorbeeld betrekking hebben op het niet vragen van een meisjesnaam indien de invuller van het formulier eerder bij ‘geslacht’ heeft aangegeven een man te zijn.

-

Logica Onder logica betreffende elektronische formulieren wordt verstaan het controleren van de juistheid en/of volledigheid van hetgeen er wordt ingevuld. Dit kan bijvoorbeeld een al dan niet verplicht in te vullen veld zijn, maar ook een bepaald formaat als datum, sofi-nummer (elfproef), (alfa)numeriek, en dergelijke. Er wordt onderscheid gemaakt tussen zogeheten singlefield en multifield validaties, waarbij in het eerste geval validatie slechts betrekking heeft op één enkel veld op het formulier en in het tweede geval op de relatie tussen twee of meer velden. Ook validatie van de gegevens tegen een externe bron, bijvoorbeeld een gegevensmagazijn, worden hiertoe gerekend. Validatie vindt tenminste plaats op de server en bij voorkeur ook zo veel mogelijk op de client.


30


Prefill Onder ‘prefill’ wordt verstaan het vooraf invullen van reeds bekende gegevens (zoals NAW-gegevens) op het formulier, nadat iemand zich heeft geauthenticeerd, met name vanuit het gegevensmagazijn (zie paragraaf 5.1.3). Wanneer iemand bij het invullen van een formulier incorrect geregistreerde gegevens tegenkomt, kan tijdens het invullen van het formulier een wijzigingsverzoek gedaan worden.

-

Formulierexecutie en -verwerking Formulierexecutie heeft betrekking op de manier waarop invullers bijgestaan kunnen worden bij het invullen van een formulier, tot en met het moment van verzenden ervan. Dit betreft bijvoorbeeld een ‘wizard’ modus waarin stapsgewijs de veld(blokk)en van het formulier worden gepresenteerd zodat men te allen tijde terug kan in het invulproces (zonder verlies van gegevens). Ook tussentijds opslaan om later verder te kunnen gaan en het kunnen meesturen van bijlagen vallen hieronder, evenals een recapitulatie van de ingevulde gegevens (zulks in verband met opslaan/printen) voor het definitief verzenden ervan. Formulierverwerking heeft betrekking op wat er plaatsvindt zodra een ingevuld formulier verzonden is en hoe.

•

Vraaggeleiding en product/dienstencatalogus Vraaggeleiding betreft de wijze waarop ‘klanten’ begeleid kunnen worden om vanuit hun vraag het juiste gemeentelijke ‘product’ te kunnen vinden. Naast de bekende vraagpatronen zoals alfabet, levensgebeurtenis of lijst is zoekfunctionaliteit belangrijk, evenals zogeheten kennis- of beslisbomen. Via dergelijke beslisbomen kunnen klanten, middels het doorlopen van een beperkt aantal vragen, de gewenste informatie (informatievraag) of het benodigde formulier (productaanvraag) ‘vinden’ Als zodanig fungeert deze functionaliteit als een soort ‘informatieportaal’ waarmee zowel klanten als FO/KCC-medewerkers producten kunnen vinden. Ook hier is een zekere geavanceerde functionaliteit ten aanzien van dergelijke beslisbomen van belang, zoals het kunnen ‘terugstappen’ in het vraagproces of het tussentijds opslaan om later verder te kunnen gaan, beide zonder verlies van reeds verstrekte informatie. Het beoogde gebruik van de functionaliteit op het gebied van vraaggeleiding bestaat eruit dat medewerkers van een gemeente, zonodig met enige training doch zonder dat kennis van html en dergelijke vereist is, beslisbomen kunnen ontwikkelen en beheren. Indien van toepassing worden gedurende dit proces al verstrekte gegevens overgenomen op het uiteindelijk aldus ‘gevonden’ aanvraagformulier (vergelijk ‘prefill’). Uiteindelijk hebben de gemeenten in het Consortium ook de intentie om onderling beslisbomen uit te wisselen. Het proces van vraaggeleiding gaat aldus, met een eventuele tussenstap voor authenticatie (DigiD), naadloos over in het invullende van het formulier, weer zonder verlies van reeds verstrekte informatie. Het gebruik van de beslisbomen is rubriceerbaar en meetbaar en om te zetten in statistieken (managementinformatie), bij voorkeur te specificeren naar type gebruiker (zoals bedrijven, burgers en medewerkers). Aldus is het bovendien mogelijk om een overzicht te genereren van het doorlopen vraagproces, dat tevens geprint kan worden. De functionaliteiten ten behoeve van dergelijke vraaggeleiding zijn nauw verweven met de zogeheten (G)PDC, de (gemeentelijke) product/dienstencatalogus.


31


Authenticatie en autorisatie Elektronische formulieren kunnen bovendien ook voor andere kanalen dan alleen burgers gebruikt worden, zoals aan de balie en in een callcenter (ook ‘namens’ een burger), maar ook voor E-mail en zelfs voor postregistratie. Hiertoe is echter wel bepaalde functionaliteit benodigd zoals op het gebied van authenticatie en autorisatie, die het mogelijk maakt dat bijvoorbeeld een baliemedewerker op een formulier een bepaald veld wel kan invullen of anderszins informatie kan zien, welke voor een burger niet zichtbaar is. Authenticatie en autorisatie hebben derhalve niet alleen betrekking op burgers (DigiD) en bedrijven (DigiD voor bedrijven), maar ook op medewerkers. Met name de niveaus waarop geautoriseerd kan worden (zoals rollen, individu, en groepen) en rechten kunnen worden toegekend zijn hierbij relevant, evenals eventuele integratie met tools voor identity management, portals, content management systemen en andere applicaties die authenticatie vereisen zoals een WOZ-portaal (‘single sign-on’).

•

Elektronisch betalen Voor elektronisch betalen kan onder meer gebruik gemaakt worden van de diensten die Ogone op dat gebied biedt. Gemeenten maken bovendien onderscheid tussen vooraf en achteraf betalen, alsmede tussen gegarandeerde (bijvoorbeeld machtiging, creditcard, iDeal en dergelijke) en niet gegarandeerde betalingen (bijvoorbeeld acceptgiro, overboeking en dergelijke). Bovendien is het van belang om na ontvangst van een betaling in het financiële systeem deze te kunnen matchen met de desbetreffende ‘zaak’ (bijvoorbeeld een productaanvraag).

•

Personalisatie Personalisatie heeft in dit kader betrekking op het aanbieden van informatie zoals statussen aan klanten, nadat deze zich geauthenticeerd hebben. Denk hier bijvoorbeeld ook aan een ‘Mijn Gemeente’ pagina met gepersonaliseerd nieuws, aangevraagde bouwvergunningen in de nabije omgeving, statussen van lopende zaken, meldingen als “uw paspoort verloopt volgende maand” en dergelijke. Ook de landelijke ontwikkelingen op het gebied van de Persoonlijke Internetpagina (PIP) vallen hieronder, evenals het ontsluiten van documenten als ingevulde formulieren, originele vergunningen, correspondentie en dergelijke via dergelijke gepersonaliseerde interfaces. Bovendien zou dergelijke functionaliteit ook gebruikt kunnen worden om medewerkers van de gemeente inzicht te geven in deze gegevens (analoog aan hetgeen hiervoor onder ‘authenticatie en autorisatie’ genoemd is). Zowel klanten als medewerkers kunnen aldus geïntegreerd en in samenhang (dat wil zeggen niet-conflicterend en consistent) bepaalde informatie krijgen.

•

Zoeken Zoeken heeft in deze context betrekking op het kunnen indexeren en doorzoeken van verschillende gegevens(bronnen) zoals formulieren, de product/dienstencatalogi, websites, (gegevens- en zaken)zakenmagazijnen en andere databases, applicaties, documenten en dergelijke, zowel door klanten als medewerkers. Bovendien spelen hierbij de mate waarin er verschillende zoekmethoden worden ondersteund een rol, evenals de mate waarin eventuele, meer en minder geavanceerde, extra functionaliteiten worden ondersteund.

•

Geo-informatie Dit betreft in het bijzonder het kunnen presenteren van de aanwezige (basis)gegevens in een geografische context in een webbrowser, zoals de presentatie van kaarten, de projectie van geografische en administratieve (basis)gegevens op die kaarten en de opslag van


32


dergelijke gegevens (in het kader van de toekomstige verplichting van gemeenten om bepaalde geometrische gegevens te koppelen aan de bijbehorende administratieve gegevens). Bovendien willen gemeenten informatie gepersonaliseerd kunnen presenteren in een geografische context, zoals het tonen van bouwergunningen in de eigen buurt en het kunnen aanklikken van een bepaalde locatie in het kader van bijvoorbeeld een melding openbare ruimte en de prefill van eventuele relevante gegevens op het betreffende formulier. •

Managementinformatie In aanvulling op de reeds genoemde functionaliteiten op dit gebied (zie‘vraaggeleiding’) is het mogelijk om verschillende relevante overzichten te genereren (managementinformatie) zowel cijfermatig als in grafiekvorm. Hierbij kunnen gebruikers zelf een selectie maken van in de informatiesystemen voorkomende velden en de sorteervolgorde bepalen, zoals aanvragen per product(groep), per periode, per status, per medewerker, per rol, per afdeling en dergelijke. Dit kan zowel betrekking hebben op standaardrapportages als op meer complexe ad-hoc rapportages, welke in beide gevallen opgeslagen, uitgeprint en digitaal verzonden en bovendien door de medewerkers van de gemeente zelf samengesteld kunnen worden.

5.1.3 Klantcontactcentrum Het klantcontactcentrum omvat verschillende functionaliteiten, waaronder processturing en gegevensopslag, die het mogelijk maken om elektronische formulieren ook voor additionele kanalen in te zetten bovenop het klant / webkanaal. Dit heeft bijvoorbeeld betrekking op de dienstverlening bij de balie, aan de telefoon (callcenter) en zelfs voor postregistratie. •

Gegevensmagazijn Het gegevensmagazijn, ook wel operational data store (ODS), dient voor de replicatie en synchronisatie 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 als het backoffice dit niet is (zogeheten ‘koude’ data). Zo kan het gegevensmagazijn worden ingezet voor bijvoorbeeld DigiD- authenticatie en het vooraf invullen (‘prefill’) van (basis)gegevens op formulieren, alsmede voor validatie van ingevulde gegevens. De synchronisatiefrequentie (bijvoorbeeld één keer per dag) bepaalt de actualiteit van de gegevens in het gegevensmagazijn en kan door gemeente naar haar eigen inzicht worden bepaald. Doordat in het gegevensmagazijn gestructureerde gegevens op een centrale plaats beschikbaar zijn, kunnen deze bijvoorbeeld gebruikt worden als basisregistraties en kan het gegevensmagazijn ingezet worden voor de ontsluiting van gestructureerde (basis)gegevens naar zowel klanten als medewerkers.

•

Zakenmagazijn In tegenstelling tot het gegevensmagazijn wordt in het zakenmagazijn ook geschreven. Het zakenmagazijn bevat dan ook zogeheten ‘warme’ data oftewel procesgegevens van zowel lopende als afgehandelde zaken. Het zakenmagazijn, dat in de visie op elektronische dienstverlening een prominente plaats inneemt aangezien hierin de zaakgerichte werkwijze tot uitdrukking komt, dient dan ook te worden ingericht volgens het GFO-zaken. Op deze wijze kan de ‘zaak’ centraal worden gesteld in het werkproces en niet het document.


33


Het zakenmagazijn vormt als zodanig namelijk de verbinding tussen de werkprocessen, de procesinformatie en de (basis)registraties (middels het opbouwen van zaakdossiers waarin al deze aspecten tot uitdrukking komen). Bovendien is het zakenmagazijn de omgeving waarin, analoog aan het ‘dikke’ midoffice concept, de zogeheten ‘applicatieloze’ producten kunnen worden geregistreerd en afgehandeld (zie ook verderop, onder het kopje ‘generieke applicatie’). Doordat in het zakenmagazijn procesgegevens rondom zaken (bijvoorbeeld zaakdossiers, statusinformatie en dergelijke) op een centrale plaats beschikbaar zijn, kunnen deze ook intern geraadpleegd worden, bijvoorbeeld voor informatieverstrekking door medewerkers van de gemeente. Als zodanig behelst het ontsluiten van statusinformatie één van de meest belangrijke functies van het zakenmagazijn. In de beoogde situatie zijn gemeenten zelf in staat om per product te bepalen welke statusinformatie op welk moment wordt verstrekt. Uiteindelijk hebben de gemeenten in het Consortium ook de intentie om onderling zaken als datamodellen en dergelijke uit te wisselen (bijvoorbeeld ten behoeve van de inrichting van het gegevens- en/of zakenmagazijn). Bij het gegevens- en zakenmagazijn is dan ook de (gemeentespecifieke) inrichting van groot belang. Denk hierbij aan zaken als flexibiliteit, schaalbaarheid en datamodellen (GFO’s), maar ook aan replicatie, synchronisatie en de mate waarin al rekening wordt gehouden met de invoering van basisregistraties, het Burger Services Nummer (BSN) en dergelijke. •

Generieke applicatie Doordat het midoffice met het zakenmagazijn over een eigen gegevensopslag beschikt waar ook in geschreven kan worden, ontstaat de mogelijkheid één en ander als een soort ‘generieke applicatie’ in te zetten waarbij de dienstverlening over alle kanalen via dezelfde interface (elektronische formulieren) wordt ondersteund. Bovendien wordt de afhandeling van eenvoudige producten zoveel mogelijk ‘naar voren’ (frontoffice) gebracht en vindt de administratieve afhandeling en registratie niet langer in een specifieke procesapplicatie in het backoffice plaats. Eén en ander vereist wel een adequate inrichting van het midoffice, met name voor wat betreft het zakenmagazijn en de interface daarop. Die interface, welke ook wel eens als ‘zaakbehandelaar’ wordt aangeduid, is de omgeving waarin ingediende zaken in behandeling kunnen worden genomen. Voor zover het zaken betreft die betrekking hebben op producten waarvan de administratieve afhandeling en registratie niet in specifieke backoffice applicaties plaatsvinden, vormt de zaakbehandelaar dus een generieke ‘backoffice applicatie’. Binnen deze interface kunnen medewerkers de status van een zaak veranderen, hetgeen vervolgens automatisch zichtbaar wordt voor de aanvrager (op het web, bijvoorbeeld in diens ‘Mijn Gemeente’ omgeving). Desgewenst kan hier ook een (automatische) E-mail met notificatie dat de status is gewijzigd worden verstuurd.

•

Beperkt workflow management (WfM) In aanvulling op de zogeheten ‘applicatie workflow’ (BPM, zie ook paragraaf 5.1.4) is voor het afhandelen van zaken en andere beoogde toepassingen van de Midoffice Suite, zoals voortgangsbewaking bij bezwaarschriften voor zover deze niet in een specifieke procesapplicatie plaatsvindt, ook behoefte aan ‘menselijke’ workflow (WfM.). Dergelijke WfM onderscheidt zich van BPM door het gebruik van werkvoorraden, taakbakjes en dergelijke. Zoals gezegd is hier, in het kader van het beoogde gebruik, slechts behoefte aan relatief beperkte workflow management functionaliteit. Dit betreft zogeheten horizontale of generieke workflow management functionaliteit in het klantcontactcentrum, zulks in


34


tegenstelling tot de verticale of specifieke workflow management functionaliteit in het backoffice. Aldus kan bepaalde informatie (zoals poststukken, E-mails en andersoortige documenten) die bij een bepaalde taak hoort door de organisatie gerouteerd worden. Bij het proces waarin de opeenvolging van dergelijke taken wordt weergegeven kunnen zowel seriële als parallelle ‘stappen’, welke door een medewerker kunnen worden uitgevoerd, overgedaan of overgeslagen worden. Voor zulke stappen en processen, bestaande uit een opeenvolging van dergelijke stappen, kunnen minimale / maximale en vaste / flexibele doorlooptijden worden aangegeven. Bovendien wordt de statusinformatie van de betreffende zaak met de voortgang van het proces geüpdate (handmatig of - bij voorkeur - automatisch). De werkprocessen in het klantcontactcentrum kunnen met deze functionaliteit vraaggericht en laagdrempelig worden ingericht. Voor het modelleren van die processen is bij voorkeur een tool beschikbaar met een grafische interface. Aldus kunnen medewerkers van een gemeente, zonodig met enige training doch zonder dat hiertoe een uitgebreide technische kennis van programmeertalen en dergelijke vereist is, zelfstandig additionele processen ontwikkelen en beheren. Uiteindelijk hebben de gemeenten in het Consortium de intentie om onderling dergelijke processen uit te wisselen. Vergelijkbaar met ‘Business Activity Monitoring’ bij BPM (zie paragraaf 5.1.4) worden de processen bij WfM ook nauwgezet gevolgd. Aldus kan volledig inzicht gegeven worden in de voortgang en afhandeling van zaken en documenten, zoals (dreigende) overschrijdingen van streefdata. Op basis van dergelijke informatie kan men desgewenst de werkvoorraad muteren (herverdeling van taken). In het kader van de onderhavige toepassing in een dik midoffice / KCC betreft het hier echter uitdrukkelijk relatief ‘lichte’ workflow management functionaliteit. Het beoogde gebruik ervan betreft immers niet de vervanging van de complexe backoffice workflow, maar slechts om zaken als eenvoudige voortgangsbewaking en het routeren van bepaalde informatie door de organisatie. •

Beperkt relatiebeheer (CRM) Ten behoeve van het creëren van een integraal klantbeeld over de verschillende kanalen is in het klantcontactcentrum behoefte aan beperkte functionaliteit voor relatiebeheer (CRM). Daarnaast is in dat kader de voortgangsbewaking van ‘calls’ die vanuit de eerste lijn naar de tweede lijn worden doorgezet van belang. -

Contactregistratie Dit heeft betrekking op het vastleggen van klantcontacten, ongeacht de wijze waarop het contact is gelegd (E-mail, web, telefoon, balie, post). Naast het betreffende kanaal wordt het contact ook inhoudelijk geregistreerd (waar ging het over). Aldus is men in staat de klant een overzicht te genereren van eerdere contacten en aanvragen en van de eventuele status daarvan. Bovendien kan een dergelijke contactregistratie ook intern gebruikt worden, bijvoorbeeld door medewerkers aan de balie en in een callcenter. Hierbij kan procesoverstijgend op verschillende manieren in deze registratie gezocht worden (bijvoorbeeld op klant, chronologisch, op product / proces, op medewerker, op zaak, op kanaal en dergelijke) en kunnen bovendien eventuele bijbehorende gegevens zoals documenten, formulieren, statussen en dergelijke worden ingezien.


35


Case management Dit heeft betrekking op het kunnen doorzetten van bijvoorbeeld vragen vanuit de ‘eerste lijn’ (frontoffice, bijvoorbeeld de balie of het callcenter) naar de ‘tweede lijn’ (zoals een specialist van een vakafdeling). Case management functionaliteit betreft in het bijzonder de mogelijkheid om de voortgang van een dergelijke ‘call’ (bijvoorbeeld een klacht of een vraag) te kunnen bewaken, inclusief termijnbewaking en dergelijke.

-

Afspraken Middels deze functionaliteit kunnen bovendien, ook via meerdere kanalen, afspraken worden gemaakt, zoals voor een gesprek met een belastingconsulent of baliebezoek.

-

Relatiemanagement Dit heeft betrekking op het kunnen registreren en beheren van (relaties tussen) personen en bijvoorbeeld bedrijven, zoals een overzicht van de verschillende contactpersonen per bedrijf en voor welke zaken zij het aanspreekpunt vormen. Vanzelfsprekend is hier ook de voornoemde functionaliteit van contactregistratie beschikbaar, zodat men kan zien wanneer men met wie waarover contact heeft gehad.

•

Beperkt document management (DMS) Net als bij workflow management dient in het kader van de beoogde toepassing in een dik midoffice / klantcontactcentrum benadrukt te worden dat het hier uitdrukkelijk om relatief beperkte document management functionaliteit gaat. Gemeenten die deze functionaliteit als onderdeel van de onderhavige opdracht willen aanbesteden, zoeken vooral vervanging van het huidige documentaire, bestuurlijke en raadsinformatiesysteem (respectievelijke DIS, BIS en RIS). In veel gevallen gaat het hier om de vervanging van het DocMan pakket. Het gaat daarbij dan ook met name om het invoeren van analoge (dat wil zeggen scannen van binnengekomen stukken ten behoeve van het zakenmagazijn) en digitale documenten, inclusief postregistratie en dossiervorming (zowel klant- als zaakdossiers), de opslag en het beheer van documenten (inclusief metadata), ondersteuning bij het besluitvormingsproces en relatief ‘lichte’ workflow management functionaliteit, bijvoorbeeld het kunnen routeren van documenten en het bewaken van doorlooptijden. Daarnaast spelen hierbij ook zaken als dossiervorming en archivering een rol, evenals de publicatie en ontsluiting van documenten voor zowel medewerkers (via het intranet) als voor klanten via de website (conform het Internet Publicatie Model). Het RIS en BIS zijn bij voorkeur in de website geïntegreerd en te doorzoeken via de zoekmachine van de site dan wel de ICTU (conform Webmetadata standaard). Eventuele andere functionaliteiten zijn het bieden van informatie over de samenstelling van het bestuur (smoelenboek) en de vergaderingen, agenda's en bijbehorende documenten.

•

Autorisatie Voor de meeste van de voornoemde functionaliteiten is een adequaat autorisatiemodel van groot belang. Dit betreft in het bijzonder de mate waarin rechten kunnen worden toegekend aan individuele gebruikers, groepen, rollen, afdelingen en dergelijke. Het moet mogelijk zijn om hierbij met overerving van beveiligingsniveaus te werken (bijvoorbeeld dat voor documenten binnen een dossier hetzelfde geldt als voor dat dossier). Het is wenselijk om autorisaties toe te kunnen kennen op basis van uitzondering (‘Henk mag alles behalve’) en op meerdere niveaus zoals werkprocessen, taken, gegevens (records / velden), documenten,


36


zaken, dossiers en dergelijke. Voor gebruikers is het te allen tijde volkomen duidelijk wat zij wel of niet mogen; functies waarvoor zij niet zijn geautoriseerd, worden dan ook niet getoond of zijn inactief / grijs. Ook in de toelichting op het frontoffice deel van de Midoffice Suite (paragraaf 5.1.2) is een item ‘authenticatie en autorisatie’ opgenomen. Daar is reeds het belang van een adequaat autorisatiemodel benadrukt, met name voor wat betreft de niveaus (zoals rollen, individu, en groepen) waarop geautoriseerd kan worden en rechten kunnen worden toegekend. In dat kader dient dan ook benadrukt dat de uitdrukkelijke voorkeur uitgaat naar één geïntegreerd authenticatie- en autorisatiemodel (inclusief rechten en rollen, overerving en dergelijke) dat in ieder deel van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) kan worden gebruikt en bovendien flexibel en gebruiksvriendelijk is. •

Managementinformatie Dit heeft betrekking op het genereren van verschillende typen overzichten van relevante informatie (zowel cijfermatig als in grafiekvorm). Hierbij kunnen gebruikers zelf een selectie maken van in de informatiesystemen voorkomende velden en bovendien zelf de sorteervolgorde bepalen, zoals doorlooptijden en aanvragen per product(groep), per status, per periode, per medewerker, per rol, per afdeling en dergelijke. Dit kan zowel betrekking hebben op standaardrapportages als op meer complexe ad-hoc rapportages, welke in beide gevallen opgeslagen, uitgeprint en digitaal verzonden kunnen worden, en bovendien door de medewerkers van de gemeente zelf kunnen worden samengesteld. Ook in de toelichting op het frontoffice deel van de Midoffice Suite (paragraaf 5.1.2) is een item ‘managementinformatie’ opgenomen. In dat kader dient dan ook benadrukt te worden dat één geïntegreerd managementinformatiesysteem de uitdrukkelijke voorkeur heeft, dat in elk deel van de Midoffice Suite Suite (frontoffice, klantcontactcentrum en broker) kan worden gebruikt. Eén en ander vraagt met name een doordachte opzet van het datamodel (databases, datawarehouse, gegevensmagazijn en dergelijke)

5.1.4 Broker •

Business Process Management (BPM) Een centraal onderdeel van de midoffice functionaliteiten betreft de broker. Dit betreft een message- of integratiebroker die fungeert als (ont)koppelvlak tussen fronten backoffice. De broker (letterlijk: ‘makelaar’, ook wel ESB of ‘Enterprise Service Bus’) ontvangt de elektronische berichten (XML) vanuit het webintake systeem en ‘orkestreert’ deze naar de juiste backoffice applicatie(s). Dergelijke procesorkestratie wordt ook wel Business Process Management (BPM) genoemd. Aldus kunnen aanvragen worden ‘doorgezet’ naar één of meerdere procesapplicaties, ook in de gewenste volgorde. Het gebruik van eventuele adapters hierbij wordt verderop toegelicht. Dergelijke integratie functionaliteit (Enterprise Application Integration, oftewel EAI) door middel van elektronisch berichtenverkeer (messaging) kan de berichten routeren op basis van verschillende methoden (zoals store-and-forward, request-reply, fire-and-forget en publish-subscribe) en kan zowel synchroon als asynchroon plaatsvinden. In dat laatste geval wordt een bericht gebufferd (message queueing) zolang een backoffice applicatie, om wat voor reden dan ook, tijdelijk niet beschikbaar is.


37


Daarnaast kan middels zogeheten Business Activity Monitoring (BAM) het proces in de gaten gehouden en zonodig (automatisch) bijgestuurd worden. Bovendien vindt middels logs, audit-trails en dergelijke registratie van het proces plaats, zodat bij eventuele fouten een zogeheten ‘roll-back’ kan plaatsvinden. Voor het modelleren van dergelijke processen (ook wel ‘applicatie workflow’ genoemd, welke in tegenstelling tot ‘menselijke’ workflow (zie verderop) uitsluitend plaatsvindt tussen applicaties en systemen onderling) is bij voorkeur een tool beschikbaar met een grafische interface. Aldus kunnen medewerkers van een gemeente, zonodig met enige training doch zonder dat hiertoe een uitgebreide technische kennis van programmeertalen en dergelijke vereist is, zelfstandig additionele processen ontwikkelen en beheren. Uiteindelijk hebben de gemeenten in het Consortium ook de intentie om onderling dergelijke processen uit te wisselen. •

Adapters Voor producten waarvan de administratieve afhandeling en registratie (transactie) niet in de generieke applicatie omgeving plaatsvindt maar in een specifieke backoffice applicatie, dienen gegevens naar de betreffende backoffice applicatie te worden doorgegeven (de op een aanvraagformulier ingevulde gegevens bijvoorbeeld). Hierbij is mogelijk enige mate van ‘vertaling’ (translatie / transformatie) vereist. Voor het doorgeven van gegevens naar bijvoorbeeld een backoffice applicatie dienen (ook) zogeheten adapters: stukjes software die de informatieoverdracht regelen tussen de broker en bijvoorbeeld verschillende fronten backoffice applicaties. Een adapter vormt aldus een soort koppelvlak met een applicatie, waarbij gebruikgemaakt wordt van gestandaardiseerde (functionele en technische) protocollen, inclusief validaties op basis van de ‘business rules’ in de betreffende backoffice applicatie. Bij koppelingen wordt onderscheid gemaakt tussen synchronisatiekoppelingen (voor synchronisatie van gegevens uit een backoffice applicatie met het gegevensmagazijn), transactiekoppelingen (voor het wegschrijven van gegevens in een backoffice applicatie) en statuskoppelingen (voor het teruggeven van de status van zaken zoals aanvragen, meldingen en dergelijke vanuit een backoffice applicatie naar het zakenmagazijn). Naast transactie integratie (schrijven in het backoffice) kunnen dus ook gegevens gelezen worden uit het backoffice (‘read-only’), zoals het lezen van statusinformatie uit het backoffice (voor het zakenmagazijn) en synchronisatie van het gegevenmagazijn met het backoffice. De gemeenten in het Consortium hebben de uitdrukkelijke intentie om voor alle producten een transactiekoppeling met het backoffice te realiseren. Het betreft hier een koppeling op applicatieniveau, bij voorkeur op basis van webservices, waarbij op formulieren ingevulde gegevens volledig automatisch, zonder tussenkomst van een medewerker, in de betreffende backoffice applicatie(s) worden ingevoerd met inachtneming van de applicatielogica (ook wel business rules of valdaties) van die betreffende backoffice applicatie. Synchronisatieen statuskoppelingen kunnen, in tegenstelling tot transactiekoppelingen, wel via adapters op basis van databasekoppelingen worden gerealiseerd De gemeenten in het Consortium hebben bovendien de intentie om gezamenlijk adapters van alle voornoemde typen te (laten) ontwikkelen en onderling uit te wisselen.


38


5.2

Eisen Midoffice Suite

E19

DigiD De mogelijkheid tot het gebruik van DigiD ten behoeve van authenticatie van klanten is aanwezig.

E20

Ogone De mogelijkheid tot het gebruik van Ogone ten behoeve van elektronisch betalen is aanwezig.

E21

Server platformen De deelnemende gemeenten hebben voor verschillende server platformen (operating systemen, applicatieservers, webservers, database servers en dergelijke) al bestaande overeenkomsten. Alle server componenten moeten daarom tenminste kunnen draaien op de onderstaande platformen: -

Applicatie- en webservers op Microsoft Windows 2003.

-

Databases en -servers: Oracle 9i en 10g op diverse operating systemen.


39


5.3

Vragen Midoffice Suite: frontoffice

5.3.1 Webintake V1

* Formulierontwerp Beschrijf de mogelijkheden om formulieren te creëren. Besteed hierbij onder meer aandacht aan de ontwerptool en de scheiding van vorm (bijvoorbeeld het gebruik van stylesheets), logica en intelligentie en inhoud. Geef, indien van toepassing, ook een toelichting op de mogelijkheden voor het gebruik en eventuele overerving van logica (single- en multifield validaties) en intelligentie bij formulier(onderdel)en. Geef aan of en zo ja in hoeverre bij het ontwerpen van formulieren gebruik kan worden gemaakt van zogeheten basisgegevens uit authentieke (basis)registraties, inclusief geometrie, en de huisstijl van gemeenten. Geef daarnaast aan of, en zo ja hoe, formulieren gedeeld kunnen worden met andere gemeenten (import- / exportfunctie). Ook hierbij is de scheiding van vorm, logica en intelligentie en inhoud van belang, alsmede het gebruik van open standaarden (zoals X-forms). Geef aan van / naar welke tools en op welke wijze formulieren (zonder logica, maar met opmaak zoals huisstijl) in een ander formaat (zoals PDF en MS Word) kunnen worden geïmporteerd en/of geëxporteerd.

V2

* Formulierbeheer Beschrijf de mogelijkheden voor het beheer van formulier(onderdel)en. Besteed hier onder meer aandacht aan autorisaties (rechten en rollen), versiebeheer (bijvoorbeeld check in / out, locking en dergelijke) en workflow. Geef aan of, en zo ja hoe, gebruik kan worden gemaakt van metadata bij formulieren, inclusief rechten op bepaalde metadata velden. Beschrijf ook de mogelijkheden tot het classificeren en doorzoeken van formulieren door de beheerders. Geef aan of, en zo ja hoe, overerving door formulier(onderdel)en kan worden bepaald, inclusief of, en zo ja hoe, deze gekoppeld blijven aan de originele elementen. Geef aan of, en zo ja hoe, er templates (sjablonen) kunnen worden gecreëerd en gebruikt en geef tevens aan welke er standaard meegeleverd worden. Beschrijf de mogelijkheden voor versiebeheer, met inbegrip van eventuele versieaanduiding in ingevulde formulieren. Beschrijf ten slotte of, en zo ja welke, modelleertools (zoals Mavim, Protos, Visio en BWise) kunnen worden gekoppeld ten behoeve van de ‘flow’ van formulieren.

V3

* Standaardformulieren en formulieruitwisseling Geef een lijst van standaard meegeleverde formulier(onderdel)en en beschrijf de functionaliteiten en de aanpasbaarheid hiervan. Betrek hierin tenminste de inhoud, intelligentie, logica, en vorm van de formulier(onderdel)en, alsook de mate waarin intelligentie en logica gedocumenteerd zijn. Geef bovendien aan welke statussen, prefills en validaties (zowel single- als multifield, tegen het gegevensmagazijn, het zakenmagazijn en eventuele andere bronnen) hierbij onderkend worden. NB: de beoordeling vindt plaats op basis van de relevantie voor gemeenten.


40


Beschrijf de importen exportmogelijkheden van / naar andere webintake oplossingen; dit in verband met de uitwisseling met andere gemeenten. Denk hierbij onder meer aan onafhankelijkheid voor wat betreft vormgeving, technische infrastructuur en dergelijke maar ook aan de gebruikte import- / exportformaten en open standaarden voor import / export van functionaliteiten (inclusief logica, intelligentie en dergelijke). V4

* Formulierexecutie: basisfunctionaliteiten Beschrijf de mogelijkheden om gebruikers te ondersteunen tijdens het invullen van formulieren. Besteed hier onder meer aandacht aan prefill uit een gegevensmagazijn en/of eerder ingevulde formulieren, de mogelijkheid om een formulier tussentijds op te slaan om later verder te gaan, alsook aan de mogelijkheid om volledig ingevulde formulieren op te slaan (elektronisch en als PDF) en te printen, inclusief opmaak (huisstijl). Beschrijf hierbij ook hoe de interactie verloopt met andere onderdelen van de Midoffice Suite, zoals de broker en het gegevens- en zakenmagazijn. Beschrijf de mogelijkheden met betrekking tot zogeheten singlefield validatie van de ingevulde gegevens (zie ook paragraaf 5.1.2). Geef aan welk type validaties mogelijk zijn, zoals postcode, (alpha)numeriek, E-mail en tekstlengte. Geef bovendien aan of de betreffende validaties clientside en/of serverside plaats kunnen vinden en beschrijf hierbij ook hoe eventuele interactie verloopt met andere onderdelen van de Midoffice Suite, zoals de broker en het gegevens- en zakenmagazijn. Geef bovendien aan of, en zo ja hoe, klanten een wijzigingsverzoek kunnen doen als zij gegevens tegenkomen die incorrect zijn en geef ook hier aan hoe interactie verloopt met andere onderdelen van de Midoffice Suite. Beschrijf in dat kader ook de wijze waarop de beveiliging van gegevens geborgd is.

V5

Formulierexecutie: extra functionaliteiten Beschrijf de mogelijkheden van de formulieromgeving met betrekking tot zogeheten multifield validaties (dat wil zeggen dat meerdere eventueel op verschillende pagina’s gegeven antwoorden aan elkaar worden gerelateerd). Beschrijf ook de functionaliteiten voor niet-standaard validaties (zoals het gebruik van regular expressions en proprietary of standaard scripttalen als VBScript, JavaScript) en geef aan of, en zo ja hoe en door wie, nieuwe standaardvalidaties kunnen worden aangemaakt op basis van deze nietstandaard validaties. Geef aan of, en zo ja hoe, zogeheten ‘hidden fields’ kunnen worden gebruikt en of, en zo ja hoe, validaties met externe bronnen zoals het gegevensmagazijn kunnen worden gedaan. Geef ook aan of, en zo ja hoe, standaardvalidaties (zoals postcode) kunnen worden toegevoegd en aangepast. Beschrijf de intelligentie binnen en rondom formulieren. Denk hierbij onder meer aan het gebruik van referentietabellen. Geef aan of, en zo ja hoe, formulieren offline (dat wil zeggen zonder internetverbinding) kunnen orden ingevuld en hoe rekening wordt gehouden met eventuele versieverschillen en serverside validaties. Beschrijf ten slotte de mogelijkheden voor het presenteren van formulieren als ‘wizards’ (bij formulieren met meerdere schermen moet een voortgangsindicatie zichtbaar zijn, zoals “scherm 1 van 3” of iets dergelijks) en in meerdere talen (bij voorkeur met behulp van een taalparameter bij het starten van een formulier, zodat het slechts eenmaal hoeft te worden onderhouden).


41


V6

* Formulierverwerking Beschrijf op welke manieren ingevulde formulieren kunnen worden geregistreerd en verwerkt. Denk hierbij aan printen, opslaan als PDF (ingevulde formulieren kunnen naar keuze ook als PDF naar de klant gemaild worden), ontvangstbevestigingen en dergelijke. Geef aan hoe de ingevulde gegevens naar het midoffice getransporteerd worden (bijvoorbeeld via XML, Xforms, E-mail, naar een database, via webservices en dergelijke) en geef aan of hierbij gebruik wordt gemaakt van standaard koppelvlakken. Geef ook aan hoe deze gegevens worden weergegeven (bijvoorbeeld XML, PDF, plain tekst en dergelijke of een combinatie hiervan)., alsmede op welke wijze gekoppeld kan worden met mail- en printservers en dergelijke (zoals voor het aan klanten verzenden van ontvangstbevestigingen per E-mail / post). Beschrijf of, en zo ja hoe, separaat van het ingevulde webformulier opgestuurde fysieke (originele) documenten kunnen worden gematched. Beschrijf hoe de ingevulde gegevens naar de juiste ontvangers kunnen worden verzonden. Denk hierbij aan het afhankelijk van de inhoud en/of context verzenden van een formulier naar specifieke afdelingen, rollen, personen en dergelijke. Geef hierbij ook expliciet aan hoe wordt omgegaan met eventuele attachments bij een formulier.

V7

* KCC formulieren Beschrijf de mogelijkheden om webformulieren in te zetten bij alle kanalen, inclusief post (postregistratie), balie, telefoon (callcenter) en E-mail. Geef aan of, en zo ja hoe, FO/KCC-medewerkers (bijvoorbeeld medewerkers aan de balie en in het callcenter) namens een klant dezelfde formulieren kunnen invullen. Besteed hierbij onder meer aandacht aan eventuele al dan niet zichtbare en bewerkbare informatie afhankelijk van de rol, alternatieve manieren van authenticatie, extra beschikbare metadata, het versturen van bevestiging aan de klant en dergelijke. Beschrijf ten slotte de eventuele (beheer)mogelijkheden van de geoffreerde applicatie(s) op het gebied van E-mail management en - tracking, zoals het monitoren van inkomende E-mail, het volgen, doorgeleiden en/of afhandelen van E-mail en het bewaken van servicenormen (zoals de antwoordtermijn).

5.3.2 Vraaggeleiding en product/dienstencatalogus V8

Vraaggeleiding Geef aan in welke mate er ondersteuning geboden wordt voor vraaggeleiding en beslisbomen. Beschrijf de mogelijkheden en geef aan of, en zo ja hoe, informatie uit en de uitkomst van deze vraaggeleiding / beslisbomen in formulieren kan worden gebruikt (bijvoorbeeld voor prefill). Geef hierbij bovendien aan of, en zo ja hoe, een FO/KCC-medewerker gebruik kan maken van dezelfde functionaliteiten. Beschrijf de functionaliteiten om vraaggeleiding / beslisbomen te ontwerpen, te testen, in te voeren en te beheren. Beschrijf alle mogelijkheden waarop een overzicht kan worden verkregen van de beschikbare formulieren, zoals op alfabet, lijst, doelgroep, levensgebeurtenis, via een kaart (op coördinaat), middels zoeken en dergelijke.


42


V9

* Product/dienstencatalogus Beschrijf de functionaliteiten van de geoffreerde PDC vanuit de rol van de klant en geef aan of, en zo ja hoe, FO/KCC-medewerkers gebruik kunnen maken van dezelfde functionaliteiten als klanten kunnen. Beschrijf de functionaliteiten om een PDC op te zetten, te beheren en aan klanten aan te bieden. Geef aan of, en zo ja hoe, voor het beheer van de content in de PDC gebruik gemaakt kan worden van een CMS en geef aan welke CMS-en ondersteund worden. Geef ten slotte aan of het voor gemeenten mogelijk is zich te ‘abonneren’ op updates van de PDC. Beschrijf de integratie van de PDC met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen de frontoffice applicatie(s) en de midoffice (klantcontactcentrum en broker) applicatie(s). Betrek in uw antwoord op deze vraag zowel het Samenwerkende Catalogi project van ICTU als het zogeheten ‘no wrong door’-principe. Geef ten slotte aan of, en zo ja hoe, informatie uit en de uitkomst van het zoeken in de PDC gebruikt kan worden bij formulieren (bijvoorbeeld voor prefill), vraaggeleiding en dergelijke.

5.3.3 Authenticatie en personalisatie V10

* Authenticatie en SSO Beschrijf de mogelijkheden ten aanzien van identificatie (onbekend in het betreffende trustdomein) en authenticatie (reeds bekend in het betreffende trustdomein). Denk hier onder meer aan verschillende rollen (zoals burgers, bedrijven en verschillende groepen medewerkers). Beschrijf hoe DigiD gebruikt wordt voor authenticatie doeleinden en geef aan of deze authenticatie in het front- of midoffice wordt afgehandeld. Geef aan of, en zo ja hoe, u gebruik maakt van DigiD voor bedrijven en/of andere manieren om bedrijven en hun contactpersonen te identificeren. Beschrijf ook hoe omgegaan wordt met authenticatie van personen, bedrijven en dergelijke die niet voorkomen in administraties van een gemeente. Denk hierbij bijvoorbeeld aan het raadplegen van externe bronnen zoals de LRD (Landelijk Raadpleegbare Deelverzameling GBA). Geef aan welke maatregelen een gemeente moet treffen om DigiD (inclusief DigiD voor bedrijven) goed in te voeren en, op basis van bijvoorbeeld het BSN, de juiste NAW-gegevens bij bijvoorbeeld een aanvraag te halen. Neem hierbij in acht dat nog niet alle gemeenten beschikken over authentieke (basis)registraties. Geef aan of 3P frontoffice applicaties (zoals een CMS, WOZ-portaal en dergelijke) gebruik kunnen maken van dezelfde authenticatie (‘single-sign-on’ of SSO) of dat opnieuw moet worden ingelogd. Neem hierbij als voorbeeld op een situatie waarbij een klant na authenticatie in de Midoffice Suite zonder opnieuw in te loggen naar een WOZ-portaal kan gaan dat in een ASP-omgeving draait. Geef bovendien aan of, en zo ja hoe, FO/KCC-medewerkers klanten kunnen authenticeren bij telefonisch, E-mail of baliecontact en bijvoorbeeld aldus namens hen producten kunnen aanvragen.


43


Geef ten slotte aan of, en zo ja hoe, gebruik gemaakt kan worden van elektronische handtekeningen en dergelijke. Denk hierbij onder meer aan ‘What You See Is What You Sign’ (WYSIWYS), het kunnen stapelen van handtekeningen en het plaatsen van handtekeningen over attachments. V11

* Personalisatie Beschrijf de beschikbare ‘Mijn Gemeente’-achtige (portaal) functionaliteiten en betrek hierin ook het ICTU project Persoonlijke Internet Pagina (PIP); voor een toelichting op dit project, zie http://www.ictu.nl/activiteiten.html. Geef aan welke mogelijkheden er worden geboden voor statusvolging door aanvrager van ingediende formulieren. Denk hier bijvoorbeeld aan re- en proactieve notificatie, attendering op het dreigende verstrijken van deadlines en dergelijke. Maak hierbij ook, indien van toepassing, onderscheid per kanaal (zoals web, E-mail, post en dergelijke). Geef aan of, en zo ja hoe, klanten half ingevulde en/of al verzonden formulieren en de status van processen hieromtrent kan bekijken (zoals deadlines, stadia en dergelijke). Beschrijf de mogelijkheden rondom het opvragen en weergeven van persoonlijke en/of gepersonaliseerde informatie uit verschillende bronnen. Deze bronnen kunnen, naast het zaken- of gegevensmagazijn, ook andere achterliggende systemen zijn, die bij voorkeur via de broker worden ontsloten. Geef aan welke informatie klanten kunnen opvragen / inzien en of, en zo ja hoe, klanten de mogelijkheid hebben om correcties op die informatie te maken. Beschrijf welke mogelijkheden er bestaan om aan te geven welke gegevens kunnen worden gedeeld met andere, al dan niet publieke organisaties. Denk hierbij onder meer aan het PIP project, het concept van een zogeheten ‘digitale kluis’ en dergelijke. Beschrijf ten slotte of, en zo ja hoe, FO/KCC-medewerkers inzicht hebben in de bovenstaande elementen en beschrijf of, en zo ja hoe en de mate waarin, zij deze kunnen aanpassen (bijvoorbeeld gegevens en statussen).

5.3.4 Zoeken V12

Zoeken en indexeren Beschrijf welke functionaliteit standaard geboden wordt ter ondersteuning van zoeken in formulieren, de PDC en achterliggende bronnen (zoals websites, het zakenmagazijn, databases, applicaties, documenten en dergelijke) en geef aan of, en zo ja in hoeverre, hierbij rekening wordt gehouden met autorisaties, rechten en rollen (zoals openbaar, inwoner van de gemeente, specifieke klant, bepaalde medewerkerrollen en dergelijke). Geef tevens aan op welke wijze achterliggende bronnen (repositories) kunnen worden ontsloten (database, webservice, files en dergelijke), inclusief enig vereist maatwerk aan de te ontsluiten bronnen. Geef hier aan welke zoekmethoden ondersteund worden (zoals full text, boolean, fuzzy, metadata en dergelijke), inclusief ondersteuning voor verschillende talen (zoals Nederlands en Engels). Geef aan of, en zo ja in hoeverre, de zoekfunctionaliteit gebruik maakt van een thesaurus en/of synoniemenlijst en geef aan of het mogelijk is om een thesaurus en/of synoniemenlijst (bijvoorbeeld van de VNG) geïmporteerd en/of anderszins gebruikt kan worden.


44


Indien aanvullende zoekfunctionaliteiten mogelijk zijn door gebruik van 3P producten, beschrijf deze voor alle rollen (klant, FO/KCC-medewerker, beheerder en dergelijke) en geef daarbij aan wat de consequenties zijn van het inzetten van deze 3P producten. 5.3.5 Geo-informatie V13

Presentatie Beschrijf de wijze waarop wordt omgegaan met het ontsluiten van geo-informatie via een webbrowser (presentatie, GIS-viewer), zowel voor geografische gegevens (het kaartmateriaal en de te tonen objecten zoals een gemeentehuis, parkeerplaats of ziekenhuis) als de bijbehorende administratieve gegevens (bijvoorbeeld algemene informatie, maar ook specifieke vergunningen en activiteiten zoals bodemsaneringen en evenementen). Denk hierbij onder meer aan de wijze waarop geografische en administratieve gegevens aan elkaar gekoppeld worden (door middel van coördinaten en/of andere ‘sleutels’), aan het gepersonaliseerd presenteren van dergelijke gegevens (bijvoorbeeld het tonen van bouwvergunningen in de eigen buurt) en de manier waarop omgegaan wordt met de authenticatie en autorisatie dienaangaande. Maak hierbij onderscheid tussen de rollen klant, FO/KCC-medewerker en dergelijke met de bijbehorende rechten. Beschrijf de wijze waarop wordt omgegaan met het projecteren van verschillende kaartlagen over elkaar, alsmede van objecten hierop (zoals gebouwen, percelen en dergelijke, maar ook eventuele bijbehorende foto’s en andere bestanden zoals videoen geluidsfragmenten). Beschrijf hierbij tevens de mogelijkheden voor de integratie van webcontent en -formulieren, documenten en geo-informatie (bijvoorbeeld het kunnen aanklikken van een bepaalde locatie in het kader van een melding openbare ruimte). Denk hierbij ook aan prefill van relevante gegevens op een formulier (zoals het adres van de betreffende melding). Maak bij de beantwoording van deze vraag, indien van toepassing, een onderscheid tussen de verschillende rollen (zoals klant, FO/KCC-medewerker en dergelijke). Beschrijf de mogelijkheden voor het gebruik van luchtfoto’s, cyclomedische foto’s en dergelijke en de projectie van objecten hierop, alsmede voor functionaliteiten zoals zoomen, pannen, selecteren, opslaan en/of exporteren, afdrukken en het gebruik van geografische operatoren zoals cross, contain, touch, buffer, clip en intersect (maak bij de beantwoording onderscheid tussen de rollen klant en FO/KCC-medewerker). Beschrijf de mate waarin door de geoffreerde applicatie(s) voor de presentatie van geo-informatie gebruikgemaakt wordt van al dan niet domeinspecifieke (open) standaarden (zoals WebGIS, OpenGIS, ISO TC211, IMRO, ISWA, GML, NEN 3610 en dergelijke) en (bestands)formaten zoals DGN (MicroStation), DWG en DXF (AutoCAD), ESRI Coverage files (ArcInfo), SHP (ArcView), BNA (AtlasGIS), MIF/MID (MapInfo), Oracle Spatial en dergelijke.


45


5.3.6 Elektronische betalen V14

Elektronisch betalen Geef aan welke ondersteuning geboden wordt voor betaling via Ogone en geef aan of u nog andere manieren van betalen ondersteunt (en zo ja welke). Beschrijf hierbij ook aan welke voorwaarden (in de ruimste zin des woords) gemeenten moeten voldoen om betalingen via Ogone op hun website te kunnen aanbieden en deze intern te kunnen verwerken. Geef aan of, en zo ja in welke mate, betalingen dynamisch zijn opgezet en in welke mate workflow mogelijk is rondom betalen; denk hierbij aan het berekenen van de bedragen op basis van ingevulde formulieren, vooraf respectievelijk achteraf betalen, betalen bij aanvraag via verschillende kanalen (via internet, aan de balie met cash of pin, bij een informatiezuil n dergelijke), achteraf bedragen kunnen bepalen (rekening houdend met stornering en dergelijke) en de mogelijkheid om een elektronische factuur te kunnen aanbieden in de eigen internetbankieren omgeving van de klant. Beschrijf de mogelijkheden om vooraf in te stellen dat een bedrag op een bepaalde datum en tijd wijzigt (jaarlijkse tariefwijziging, bijvoorbeeld na de jaarwisseling). Geef bovendien aan of, en zo ja hoe, er gekoppeld kan worden met welke financiële systemen en het gegevensmagazijn (zie voor de financiële systemen van de gemeenten bijlage 8.11). Beschrijf hierbij ook de wijze waarop een elektronische betaling kan worden gematched met de financiële administratie. Geef ten slotte aan of, en zo ja de wijze waarop, informatie over een betaling wordt opgeslagen, bijvoorbeeld in het gegevens- en/of zakenmagazijn, in een (zaak)dossier en dergelijke.

5.3.7 Overig V15

Additionele functionaliteiten Hier kunt u additionele functionaliteiten van de aangeboden applicatie(s) beschrijven die in het kader van deze paragraaf 5.3 weliswaar relevant zijn maar waar niet naar gevraagd wordt.


46


5.4

Vragen Midoffice Suite: klantcontactcentrum

5.4.1 Gegevensmagazijn V16

* Inrichting Beschrijf de opzet van het gegevensmagazijn, welke onder meer gebruikt kan worden ten behoeve van prefill en validaties bij formulieren. Denk hierbij onder meer aan de plaatsing, het datamodel, flexibiliteit (zoals uitbreidbaarheid van het datamodel met andere gegevenssets), synchronisatiemogelijkheden met gegevensbronnen in het backoffice, en het gebruik hierbij van validaties, (open) standaarden (zoals STUF) en dergelijke. Beschrijf hoe het gegevensmagazijn gevuld/bijgewerkt wordt en geef aan of het synchroniseren van het gegevensmagazijn performance consequenties heeft voor het functioneren van productiesystemen alsmede of, en zo ja hoe, eventuele rollback’s in die systemen verwerkt worden in het gegevensmagazijn. Beschrijf of, en zo ja hoe, kan worden gezorgd dat privacygevoelige gegevens niet buiten de voorste firewall opgeslagen worden. Denk hierbij ook aan de mogelijkheden om gegevens versleuteld op te slaan. Beschrijf de mogelijkheden ten aanzien van opslag, replicatie en vooral synchronisatie van gestructureerde gegevens (velden / records) inclusief geografische gegevens (zoals in een GIS datawarehouse) uit het backoffice in / van / met het gegevensmagazijn. Besteed hierbij onder meer aandacht aan database views, het omgaan met diakrieten, synchronisatie op basis van zogeheten delta’s (uitsluitend wijzigingen doorgeven in plaats van als batch) en dergelijke, en aan eventuele semi-gestructureerde gegevens (zoals documenten in een DMS repository) in het gegevensmagazijn. Geef hierbij ook aan hoe het gegevensmagazijn zich tot reeds aanwezige datawarehouses, zoals een GIS datawarehouse, en hoe deze als gegevensmagazijn zouden kunnen fungeren. Het kan voorkomen dat een klant (in dit geval een burger) nog niet is opgenomen of geactualiseerd in het GBA-systeem (bijvoorbeeld vanwege een zojuist elektronisch doorgegeven verhuizing), maar al wel producten aanvraagt bij de gemeente. Beschrijf hoe hier mee wordt omgegaan (denk aan tussentabellen, voorlopige toestemming en dergelijke). Geef bovendien aan hoe gegevens over niet-ingezetenen van een gemeente in het gegevensmagazijn kunnen worden opgenomen (bijvoorbeeld via GBA / LRD koppelingen en dergelijke). Beschrijf ten slotte uw visie op het gegevensmagazijn en het gebruik daarvan, in het bijzonder voor wat betreft het gegevensmodel en besteedt hierbij tenminste aandacht aan de relatie van een dergelijk gegevenmagazijn tot het gemeentebreed (in)voeren van een stelsel van authentieke basisregistraties en de rol die het daarbij kan spelen (bijvoorbeeld of, en zo ja in hoeverre en hoe, u reeds rekening houdt met de overgang naar het Burger Service Nummer en hoe u ervoor kunt zorgen dat deze overgang goed verloopt). Besteedt hierbij bovendien aandacht aan de rol die het gegevensmagazijn kan spelen bij zogeheten datadistributie.

V17

* Ontsluiting Beschrijf de mogelijkheden voor het opzoeken en ontsluiten van gestructureerde (basis)gegevens (velden / records) uit het backoffice, een GIS datawarehouse en


47


dergelijke via het gegevensmagazijn. Denk aan de gebruikelijke (basis)registraties, WOZ-gegevens, vergunningen en dergelijke. Beschrijf hierbij ook de mogelijkheden om dit in een geografische context te doen (projectie op kaart), alsook hoe omgegaan wordt met authenticatie (zoals DigiD) en personalisatie (zowel in een geografische, zoals ‘vergunningen in de buurt’, als niet-geografische context). Maak hierbij steeds onderscheid tussen de rollen ‘klant’ en ‘medewerker’ en geef steeds aan of, en zo ja in hoeverre, de gevraagde functionaliteiten voorzien zijn van een gebruikersinterface gebaseerd op webtechnologie (te integreren met webtoepassingen). Beschrijf de mogelijkheden met betrekking tot ontsluiting van niet-persoonsgebonden informatie zoals bekendmakingen, dossiers, aanvragen, vergunningen, verordeningen, bestemmingsplannen en dergelijke. Geef hierbij, indoen van toepassing, ook aan of, en zo ja welke, relevante (open) standaarden (zoals DURP voor bestemmingsplannen, het zogeheten Internet Publicatie Model en de ‘richtlijn metadata’ van overheid.advies.nl, STUF en dergelijke) en dergelijke gebruikt worden en beschrijf hoe de interactie verloopt met verschillende bronnen (naast het gegevensmagazijn kan dit ook het zakenmagazijn of achterliggende systemen betreffen, die bij voorkeur via de broker worden ontsloten). V18

Geo-informatie Beschrijf de wijze waarop door de geoffreerde applicatie(s) omgegaan wordt met de opslag van en autorisatie rondom geo-informatie, zowel voor geografische gegevens (het kaartmateriaal en de in het GIS te tonen objecten) als voor eventuele bijbehorende administratieve gegevens. Denk hierbij aan zaken zoals basisregistraties (gebouwen, adressen, percelen, objecten en geografie, inclusief coördinaten en/of andere ‘sleutels’ en de matching daartussen), het onderscheid tussen verschillende kaartlagen, 2D / 3D, vector en/of bitmap en dergelijke. NB: het betreft hier niet de beheeromgeving van de betreffende geo-informatie (de omgeving waarin het onderhoud op/van die data wordt gedaan), maar bij voorkeur een kopie van (een subset van) de gegevens die in het GIS datawarehouse / gegevensmagazijn zitten voor ontsluitingsdoeleinden. Beschrijf de mate waarin door de geoffreerde applicatie(s) in het kader van de opslag van geo-informatie gebruikgemaakt wordt van al dan niet domeinspecifieke (open) standaarden (zoals WebGIS, OpenGIS, ISO TC211, IMRO, ISWA, GML, NEN 3610 en dergelijke) en (bestands)formaten zoals DGN (MicroStation), DWG en DXF (AutoCAD), ESRI Coverage files (ArcInfo), SHP (ArcView), BNA (AtlasGIS), MIF/MID (MapInfo), Oracle Spatial en dergelijke. Gemeenten worden in de toekomst bovendien verplicht om bepaalde geometrische gegevens te koppelen aan administratieve gegevens. Beschrijf of, en zo ja hoe, de geoffreerde applicatie(s) in deze koppeling kunnen voorzien.

5.4.2 Zakenmagazijn Het zakenmagazijn is primair bedoeld voor de opslag van zaakinformatie zoals aanvragen (de ingevulde formulieren), statussen (de voortgang van zaken) en eventuele andere relevante informatie voor klanten zaakdossiers (bijvoorbeeld links naar documenten in een DMS, zoals correspondentie over de betreffende zaak, bij de aanvraag meegestuurde bijlagen en dergelijke).


48


V19

* Inrichting Beschrijf de inrichting van het zakenmagazijn. Denk hierbij aan zaken als plaatsing, datamodel (zoals gestructureerde en ongestructureerde gegevens, verwijzingen naar externe bronnen en dergelijke), flexibiliteit, validaties en dergelijke. Betrek hierin ook het Procesmodel van EGEM (zie bijlage 8.1) en het GFO-zaken. Beschrijf hoe het zakenmagazijn gevuld/bijgewerkt wordt, zowel vanuit het frontoffice als vanuit het backoffice. Geef aan of dit performance consequenties heeft voor het functioneren van productiesystemen, alsmede of, en zo ja hoe, eventuele roll-back’s in die systemen verwerkt worden in het zakenmagazijn. Geef aan of, en zo ja hoe en in hoeverre, het zakenmagazijn ondersteuning biedt voor het opslaan van aanvragen (ingevulde formulieren) en de afbeelding daarvan, statussen (de voortgang van zaken), verwijzingen naar externe bronnen (zoals basisregistraties, het gegevensmagazijn, documenten in een DMS en dergelijke) en dergelijke. Geef aan hoe één en ander wordt opgeslagen c.q. gelinkt; denk hierbij aan verwijzingen naar sleutels en dergelijke, maar ook aan de afbeelding van ingevulde formulieren (XML) en daaraan gerelateerde gegevens (zowel ongestructureerd als gestructureerd).

V20

* Ontsluiting Beschrijf of, en zo ja hoe, de geoffreerde applicatie(s) FO/KCC-medewerkers inzicht kan verschaffen in zaakdossiers, inclusief procesgegevens (zoals statussen) rondom zaken. Geef aan hoe dit kan worden bijgehouden en bewerkt, inclusief documenten (die in een DMS kunnen zijn opgenomen), het kunnen toevoegen van E-mails en dergelijke. Een zaakdossier bevat bijvoorbeeld de volgende gegevens: zaaknummer, productcategorie (zaaktype), gegevens van de aanvrager (bijvoorbeeld als links naar het gegevensmagazijn, inclusief basisregistratiedata), omschrijving, status, (links naar) documenten, behandelend ambtenaar en dergelijke. Geef aan in hoeverre dit aansluit bij de door u beoogde opzet van het zakenmagazijn. Beschrijf ook de verschillende zoekmethoden die een FO/KCC-medewerker hierbij kan gebruiken. Geef aan of, en zo ja in hoeverre, de gevraagde functionaliteiten voorzien zijn van een gebruikersinterface gebaseerd op webtechnologie (te integreren met webtoepassingen). Beschrijf de mogelijkheden om in het zakenmagazijn bepaalde queries te maken op basis van kenmerken van afzonderlijke zaken (dit is bijvoorbeeld van belang in situaties waarbij de afhandeling van een zaak geschiedt in het kader van het totaal aantal ingediende aanvragen). Beschrijf de mogelijkheden met betrekking tot ontsluiting van persoonsgebonden informatie zoals klantdossiers, aanvragen, vergunningen, en dergelijke. Geef hierbij, indoen van toepassing, ook aan of, en zo ja welke, relevante standaarden gebruikt worden en beschrijf hoe de interactie verloopt met verschillende bronnen zoals het DMS.

V21

* Dossiervorming Beschrijf de mogelijkheden tot dossiervorming in het zakenmagazijn, zoals aangaande ingevulde formulieren en bijlagen (inclusief aanvraagresultaat en procesinformatie) en aanvullende documenten zoals correspondentie, E-mails en dergelijke.


49


Beschrijf op welke wijze dossiervorming in het zakenmagazijn plaatsvindt, in het bijzonder ten aanzien het onderscheid tussen verwijzingen naar documenten in andere systemen (zoals een DMS) en daadwerkelijke opslag in het zakenmagazijn. Besteed hierbij ook aandacht aan de vraag of, en zo ja hoe, (delen van) zaakdossiers op het web gepubliceerd kunnen worden. Geef bovendien aan of, en zo ja hoe, het mogelijk is om zogeheten ‘virtuele dossiers’ te vormen; dat wil zeggen dat documenten, die zich ook in andere systemen kunnen bevinden (zoals een DMS), via verwijzingen onderdeel kunnen zijn van meerdere dossiers. 5.4.3 Beperkt workflow management V22

* Procesmodellering (A2P) Beschrijf de mogelijkheden tot het modelleren van A2P processen (‘menselijke workflow’), inclusief eenvoudige functionaliteiten zoals notificaties en status en de granulariteit daarvan (zoals per product en/of zaaktype). Denk hierbij ook aan de grafische en/of tekstuele interface, eventuele API’s en dergelijke. Denk hierbij ook aan het inrichten van taakbakjes en groepen, alsmede aan zaken als roll-back en dergelijke. Geef bovendien aan hoe en in welke mate deze tools gedocumenteerd zijn en door medewerkers van een gemeente zelf gebruikt kunnen worden. Beschrijf bovendien eventuele geavanceerde functionaliteiten zoals escalatie bij verschillende scenario’s, beschikbaarheid en doorlooptijden (in werk- respectievelijk kalenderdagen), workloads, gedeelde werkbakjes per groep of per interessegebied en dergelijke maar bijvoorbeeld ook aan versiebeheer van processen. Geef aan wat de mogelijkheden zijn rondom de werkstromen; denk aan seriële en parallelle stromen, join en fork, samenkomst van losstaande processen, prioriteiten (zoals fifo, lifo, kritiek pad, earliest due en QoS) en dergelijke. Beschrijf de mogelijkheden voor beheer van processen en de autorisaties (rechten en rollen) rondom dat beheer. Denk aan het wijzigen van standaardprocessen en het aanwijzen van rechten hierbij. Geef ook aan wat de mogelijkheden zijn rondom het genereren van documentatie over de processen, processtappen en dergelijke. Beschrijf wat de consequenties zijn van het wijzigen van standaardprocessen voor lopende processen (versiebeheer): gebruiken deze het oude proces zodat tijdelijk twee versies actief zijn, worden ze geconverteerd naar het nieuwe proces of iets anders? Beschrijf eventuele simulatiemogelijkheden bij het ontwerp van processen, inclusief het gebruik van (een mix van) historische data en menselijke testers. Beschrijf ook de mogelijkheden voor het hergebruik van process(tapp)en, subprocessen en dergelijke. Indien relevant, beschrijf de repository van de (onderdelen van) processen.

V23

* Procesexecutie Beschrijf de mogelijkheden voor uitvoering van processen inclusief statusbewaking, notificatie en monitoring. Geef aan of, en zo ja hoe, daartoe geautoriseerde personen lopende processen (ad hoc) kunnen wijzigen, of de volgorde van stappen verplicht is, of alle stappen van een proces moeten worden doorlopen of dat eventueel stappen kunnen worden overgeslagen om toch het proces af te ronden en dergelijke. Geef ook aan of, en zo ja hoe, stappen kunnen worden overgeslagen en/of overgedragen aan anderen, alsmede de mogelijkheden voor archivering van afgesloten processen.


50


Beschrijf hoe taken verdeeld worden, zoals op basis van groepen, expertise, werkdruk, taakprioriteit, nabijheid van een kritiek pad (waar de tijdsduur van nog af te leggen stappen wordt geschat) en dergelijke. Beschrijf hierbij ook de mogelijkheden voor procesbewaking (signalering bij naderen deadlines, afronding van processen wanneer alle producten aanwezig zijn, eventueel weer openen van afgesloten processen en dergelijke), escalatie (zowel op aanvraag als bij dreigende overschrijdingen van processtap of van het gehele proces en bij escalatie afhankelijk van processtap en onderwerp naar specifieke rollen en dergelijke), alsmede voor monitoring en rapportage dienaangaande (ook wel Business Activity Monitoring of BAM genoemd). Beschrijf de eventuele relatie tussen de ‘horizontale’ workflow functionaliteit in het klantcontactcentrum en de ‘verticale’ workflow functionaliteit in het backoffice en geef hierbij aan of, en zo ja hoe en in hoeverre, horizontale en verticale workflows geïntegreerd c.q. afgestemd kunnen worden. V24

Standaardprocessen en procesuitwisseling Geef een lijst van meegeleverde gemeentelijke standaardprocessen c.q. generieke applicaties en beschrijf de functionaliteiten en de aanpasbaarheid (processen, inhoud, logica, vorm en dergelijke). Denk hierbij ook aan zaken als VNG standaardprocessen, DSP’s en dergelijke. NB: de beoordeling vindt plaats op basis van de relevantie van de processen voor gemeenten. Geef aan in hoeverre hierbij gebruik kan worden gemaakt van (open) standaarden (zoals BPEL, BPMN en dergelijke) en of, en zo ja hoe, er met modelleertools als Mavim, Protos, Visio, BWise en dergelijke kan worden gekoppeld (import en export). Besteedt hierbij ook aandacht aan eventuele mogelijkheden om procesmodellen uit te wisselen met andere gemeenten.

5.4.4 Beperkt relatiebeheer V25

Relatiebeheer Beschrijf de mogelijkheden voor de modellering en het gebruik van functionaliteiten met betrekking tot relatiebeheer. Denk aan de (standaard)inrichting en de flexibiliteit van het datamodel (zoals klanten, bedrijven, overheden, leveranciers en dergelijke) en betrek hierbij zowel de standaardvelden als toe te voegen velden zoals NAW, locaties (zoals coördinaten, adressen en dergelijke), alsmede zogeheten ‘flexvelden’. Beschrijf de mogelijkheden voor het modelleren van relaties tussen objecten zoals klanten, bedrijven, contactpersonen en dergelijke. Bespreek hier onder meer de relatie met het gegevensmagazijn, het BBR en andere (basis)registraties. Beschrijf bovendien de mogelijkheden ten aanzien van het opschonen, ontdubbelen en dergelijke van data.

V26

* Afspraken Beschrijf de mogelijkheden rondom het kunnen maken van afspraken door en voor klanten die personen of afdelingen van de gemeente willen bezoeken. Beschrijf de wijze (het proces) waarop dit kan gebeuren, inclusief afstemming met de burger en de


51


betrokken medewerker / afdeling (afhankelijk van het gemeentelijke ‘product’) en het starten van processen ter voorbereiding van de desbetreffende afspraak. Beschrijf de functionaliteiten voor het bouwen van webformulieren voor het inplannen van die afspraken en de mogelijkheden tot koppeling met afsprakensystemen zoals Bavak, maar ook agenda’s in bijvoorbeeld MS Outlook / Exchange. V27

* Contactregistratie Geef aan welke functionaliteit u biedt voor het registreren van klantcontacten, het opbouwen van klantprofielen en dergelijke en beschrijf wat hierbij zoal geregistreerd wordt. Denk hierbij aan producten en diensten, inhoud, gebruikte kanalen, betrokken medewerker(s) en klant(en), tijdsduur, en dergelijke. Geef aan of, en zo ja hoe, een medewerker via verschillende ingangen (per klant, product, tijdstip en dergelijke) kan zoeken en in welke mate informatie al automatisch wordt ingevuld (zoals op basis van telefoonnummer, E-mail adres en dergelijke). Beschrijf de verschillende kanalen waar een klantcontactcentrum gebruik van kan maken voor inkomende en/of uitgaande klantcontacten. Denk aan E-mail, telefoon, web, post, balie, veld (ambtenaar gaat naar de klant), fax en dergelijke. Geef aan of, en zo ja hoe, informatie vanuit de verschillende kanalen beschikbaar is voor alle andere kanalen en systemen (zoals in het zakenmagazijn), real-time of na batchsynchronisatie. Geef aan of er beperkingen zijn indien de gemeenten volledige onafhankelijkheid wil van het door de klant gekozen kanaal om contact op te nemen met de gemeente. Geef ook aan waar onafhankelijk van het kanaal alle relevante informatie wordt opgeslagen en kan worden opgevraagd. Denk hier ook aan enige randvoorwaarden ten aanzien van authenticatie. Beschrijf ten slotte hoe de functionaliteit voor contactregistratie en klantdossiers zich verhoudt tot de andere onderdelen van de Midoffice Suite, in het bijzonder voor wat betreft het gegevens- en zakenmagazijn.

V28

Case management Beschrijf de functionaliteiten op het gebied van voortgangsbewaking van back- en midoffice processen door het frontoffice (‘volg je vraag’ vanuit de eerste lijn naar de tweede lijn) en attenderings- en rapportagemogelijkheden aan respectievelijk door klanten en medewerkers. Geef aan of, en zo ja hoe, processen gevolgd en bijgewerkt kunnen worden (inclusief autorisatie, rechten en rollen en dergelijke), inclusief escalatie. Maak hierbij onderscheid tussen eerste en tweede lijn. Maak bij attendering en escalatie bovendien onderscheid tussen verschillende opties zoals deadlines die dreigen te verlopen op (deel)processen, afwezige werknemers en dergelijke. Beschrijf ten slotte hoe de functionaliteit voor case management zich verhoudt tot de andere onderdelen van de Midoffice Suite, in het bijzonder voor wat betreft beperkte workflow management functionaliteit.

V29

Call management Beschrijf de mogelijkheden voor call management. Denk hierbij onder meer aan het beheer van callcenter agents (telefonistes m / v), CTI (inclusief nummeridentificatie),


52


VOIP, (Automatic) Call Response en dergelijke. Beschrijf tevens de mogelijkheden ten aanzien van rapportages, bijvoorbeeld in het kader van SLA’s. Denk hierbij aan aantal openstaande calls, aantal opgeloste calls en dergelijke. V30

Selfservice Beschrijf de mogelijkheden voor het bieden van zogeheten ‘selfservice’ aan klanten. Denk hierbij aan de opbouw van een kennisbank, FAQ’s, kennisbomen, communities en dergelijke en geef aan of dit ook kan worden opgezet middels de geoffreerde CRM applicatie(s) en/of middels de geoffreerde webintake- en vraaggeleidingsapplicaties(s). Beschrijf in beide gevallen de koppelmogelijkheden van en de relatie tussen CRM en de Midoffice Suite, alsmede de mogelijkheden voor FO/KCC medewerkers om van de ‘selfservice’ functionaliteiten gebruik te maken.

5.4.5 Generieke applicatie V31

* Generieke applicatie Beschrijf of, en zo ja hoe, ‘backoffice-loze’ producten zoals eenvoudige vergunningen kunnen worden afgehandeld met de Midoffice Suite als ‘generieke applicatie’ (ook wel ‘zaakbehandelaar’ genoemd). Denk bijvoorbeeld aan elektronische formulieren, werkprocessen (inclusief ‘lichte’ workflow), het (datamodel van het) gegevens- en zakenmagazijn, bemensing (inclusief autorisatie, rechten en rollen en dergelijke), metadatering en statussen, koppeling met een DMS en dergelijke. Geef ook aan of, en zo ja hoe en welke, managementinformatie ontleend kan worden aan dergelijke generieke applicaties. Beschrijf of dit kan worden gemodelleerd met de geoffreerde formulieromgeving en of hier aangepaste look&feel mogelijk is voor ‘power-users’ (denk hier bijvoorbeeld aan master/detail schermen en dergelijke). Beschrijf de standaard meegeleverde generieke applicaties, inclusief de bijbehorende formulieren en processen (een bouwvergunning, bijvoorbeeld) en geef aan welke ‘traditionele’ backoffice processen aldus, met behulp van generieke processen en gegevensmodellen, kunnen worden gerealiseerd zonder de bijbehorende backoffice applicatie(s).

5.4.6 Beperkt document management E22

De geoffreerde DMS / RMA applicatie voldoet aan de zogeheten ReMANO eisen.

V32

* Invoer analoge documenten Beschrijf de mogelijkheden rondom invoer van analoge documenten. Beschrijf hierbij ook de mogelijkheden voor het (enkel- en dubbelzijdig, per stuk en in bulk) scannen van documenten. Denk hierbij ook aan de foutafhandeling bij foutieve (bulk)invoer en verrijking van gescande documenten met metadata, maar ook aan eventuele OCR en ICR. Geef aan of, en zo ja hoe, de metadata kan worden gevuld met standaardwaarden en/of met waarden uit andere systemen (denk hier ook aan de Richtlijn Webmetadata en het zogeheten Internet Publicatie Model). Geef ten slotte aan in hoeverre metadata zelf benoemd kan worden (gebruik van vaste registratieschermen versus eigen ontwerp).


53


V33

* Postregistratie Beschrijf de mogelijkheden rondom postregistratie, zoals registratie van inkomende en uitgaande fysieke correspondentie (inclusief opname van een verwijzing daar naar in het zakenmagazijn) en de mogelijkheden voor een uitleenregistratie van fysieke documenten en dossiers. NB: een aantal van de gemeenten in het Consortium wil het geoffreerde DMS inzetten ter vervanging van hun huidige DMS / RMA applicatie DocMan van Circle Software, welke onder meer voor postregistratie wordt ingezet.

V34

Invoer digitale documenten Beschrijf de mogelijkheden rondom invoer van digitale documenten inclusief E-mail. Denk aan bulkinvoer (inclusief foutafhandeling), metadatering (op basis van een taxonomie, vrij velden, standaardwaarden en dergelijke), de documentformaten die ondersteund worden en dergelijke. Denk ook aan ODMA, WebDAV en dergelijke. Geef aan of, en zo ja hoe, gebruik gemaakt kan worden van documentsjablonen.

V35

* Documentopslag en -beheer Beschrijf de mogelijke repository / repositories van documenten. Maak onderscheid tussen technieken (database, filesystemen en dergelijke, zowel online als offline) en structuur en functionaliteit. Denk hier ook aan de mogelijkheden voor metadata en het gebruik van taxonomieën en thesauri. Geef daarnaast een opsomming van objecttypen (documenten c.q. bestanden) die kunnen worden opgenomen en geïnterpreteerd. Denk hierbij aan bestandsformaten en metadata zoals uit MS Office files, CAD-bestanden, IDv2-gegevens van MP3’s, EXIF-gegevens van JPEG-bestanden en dergelijke, alsmede aan beeld (video) en spraak (telefoongesprekken). Beschrijf de beheers- en redactiemogelijkheden, inclusief versiebeheer (en naast elkaar bestaande versies), check in / out (en beschrijvingen van wijzigingen) en conversie van documenten. Geef aan wat de mogelijkheden zijn om bulkbewerking uit te voeren.. Beschrijf hoe wordt omgegaan met de authenticiteit van documenten. Besteedt hierbij aandacht aan de wijze waarop wordt omgegaan met elektronische handtekeningen en eventuele dubbele opslag in een standaardformaat (zoals PDF) naast het originele formaat. Geef in dat laatste geval ook aan hoe wordt omgegaan met de translatie van documenten.

V36

* Dossiervorming en archivering Beschrijf de mogelijkheden voor dossiervorming van stukken bij een product / zaak. Denk hierbij ook aan zaken als DSP’s en dergelijke en maak onderscheid tussen stukken die een burger kan zien en stukken die uitsluitend medewerkers kunnen zien, alsook tussen zogeheten ‘warme’ (dynamische) en ‘koude’ (statische) dossiers. Geef aan in hoeverre het vormen van dossiers op basis van zowel elektronische (zoals E-mails) alsook fysieke documenten tot de mogelijkheden behoort en of, en zo ja hoe, documenten en dossiers gekoppeld, gesplist en/of samengevoegd kunnen worden. Denk hierbij ook aan zogeheten ‘virtuele dossiers’. Dat wil zeggen dat documenten, die zich ook in andere systemen kunnen bevinden, via verwijzingen onderdeel kunnen zijn van meerdere dossiers.


54


Beschrijf tevens de mogelijkheden ten aanzien van het archiveren van documenten en dossiers en maak hierbij onderscheid tussen documenten procesgericht archiveren. Denk hierbij bovendien aan eventuele wettelijke eisen, inclusief ReMANO, DSP’s en de zogeheten ‘basis selectielijst’ en besteed ook aandacht aan vernietiging conform de daartoe geldende weten regelgeving. Beschrijf ten slotte de eventuele mogelijkheden voor het archiveren van webcontent (van de website). V37

* Ontsluiting Beschrijf de mogelijkheden die het DMS biedt voor ontsluiting van gestructureerde (velden / records) en semi-gestructureerde gegevens (documenten). Denk onder meer aan zoekfunctionaliteit, mogelijke interfaces, weergave van relaties tussen dossiers, de presentatie van (bouw)tekeningen (alleen een ‘plat’ plaatje of ook de lagenstructuur), (semi)automatische publicatie en dergelijke. Geef aan hoe kan worden gezocht binnen repositories, bijvoorbeeld op metadata zoals bewaartermijnen, via kennisbomen, vrij zoeken (inclusief fuzzy search) en op kernwoorden (taxonomie) en dergelijke. Geef aan of, en zo ja in hoeverre, de zoekfunctionaliteit gebruik maakt van een thesaurus en/of synoniemenlijst. Geef ook aan welke mogelijkheden er zijn voor het inzien, printen en dergelijke van gegevens. Besteed hier tevens aandacht aan ontsluiting via het web (interen intranet), inclusief, koppeling met CMS en/of webintake systeem, publicatietermijnen, ontsluiting van al bestaande (klanten zaak)dossiers en dergelijke. Besteed hierbij tevens aandacht aan ontsluiting van documenten gekoppeld aan bestuurlijke vergaderingen en agenda's. Dit veronderstelt een goede koppeling tussen het DMS en het CMS en ondersteuning bij publicatie, termijnen en het vastleggen van de metadata. Beschrijf hierbij ook of, en zo ja hoe, u rekening houdt met de ‘richtlijn webmetadata’ van overheid.advies.nl en het Internet Publicatie Model. Een DMS kan volgens dit model bepaalde metadata toevoegen aan documenten en deze vervolgens beschikbaar stellen voor publicatiedoeleinden op de website, (minimaal met een hyperlink en metadata). Daar kunnen ze na aanmelding bij landelijke zoekmachines eenvoudig en snel gevonden worden (zoals op vergunningen, bekendmakingen en dergelijke, bijvoorbeeld op relevantie voor het woongebied). Maak bij uw antwoord op deze vraag onderscheid tussen de rollen klant en medewerker (zowel in het FO/KCC als in het backoffice).

V38

Kantoorautomatisering Beschrijf de mogelijkheden voor wat betreft koppeling met kantoorautomatisering en beschrijf mogelijke koppelingen met MS Office applicaties (bijvoorbeeld MS Word), OpenOffice en dergelijke, inclusief ondersteunde versies. Beschrijf de mogelijkheden voor het doen uitgaan van gerichte mailings via post en via E-mail. Denk hierbij ook aan zogeheten ‘mail merges’ en kantoorautomatisering en groupware applicaties die hiertoe worden ondersteund, inclusief versies. Beschrijf hierbij ook de exportmogelijkheden voor zowel dossiers als documenten uit het DMS en geef, indien relevant, de verhouding en koppeling met het DMS aan voor het doen van mail merges met gegevens uit verschillende systemen. Beschrijf de mogelijkheden voor het gebruik van templates hiertoe (inclusief de wijze waarop deze kunnen worden aangemaakt, beheerd en gevuld) alsmede eventuele standaard meegeleverde templates.


55


NB: de beoordeling vindt plaats op basis van de relevantie van de templates voor gemeenten. V39

Ondersteuning besluitvorming Beschrijf de mogelijkheden die het DMS biedt voor wat betreft de ondersteuning van het besluitvormingsproces, van de creatie van een bestuurlijk advies tot de agendering, elektronische parafering en vastlegging van de besluitvorming. Denk hierbij ook aan functionaliteit zoals onderhoud van vergaderingen (zoals bijvoorbeeld het vaststellen van vergaderdata, agenderen, overplaatsen, verwijderen en dergelijke) inclusief de bijbehorende stukken. Dit laatste heeft bijvoorbeeld betrekking op het (over)plaatsen van documenten op één of meerdere vergaderingen, het publiceren ervan op het interen intranet, het samenvoegen met een lijstsjabloon en dergelijke, waarbij (groepen van) documenten vanuit een zoekresultatenlijst of vergaderoverzicht te selecteren en (groepsgewijs) te bewerken zijn. De besluitvormingsinformatie van een document dient (zowel vanuit de resultatenlijst als vanuit het besluitvormingsproces) met één handeling liefst in één oogopslag zichtbaar en duidelijk te zijn. Beschrijf hierbij ook eventuele specifiek op besluitvormingsdocumenten gerichte zoekmogelijkheden, zowel op inhoud (full text) als op metagegevens en de combinatie daarvan. Denk hierbij aan verschillende typen vergaderingen, reeds voordefinieerde zoekingangen voor agenda’s / verslagen van bepaalde bestuursorganen, beleidsnota’s, verordeningen, vergunningen en dergelijke.

5.4.7 Overig V40

Additionele functionaliteiten Hier kunt u additionele functionaliteiten van de aangeboden applicatie(s) beschrijven die in het kader van deze paragraaf 5.4 weliswaar relevant zijn maar waar niet naar gevraagd wordt.


56


5.5

Vragen Midoffice Suite: broker en technische architectuur

5.5.1 Broker V41

* Procesmodellering (A2A) Beschrijf de mogelijkheden tot het modelleren van A2A processen in het midoffice. Denk hierbij onder meer aan de grafische interface, enige API’s en dergelijke, alsmede aan STP, versies van processen, het modelleren van roll-back en dergelijke. Geef ook aan hoe en in welke mate deze tools gedocumenteerd zijn en door de medewerkers van een gemeente zelf gebruikt kunnen worden. Beschrijf de mogelijkheden tot het modelleren van A2A processen in het midoffice, zoals seriële en parallelle processen, joins en forks, wachtstanden, het aanroepen van externe systemen en prioriteiten (bijvoorbeeld fifo, lifo, kritiek pad, earliest due, QoS en dergelijke). Geef bovendien aan of, en zo ja in hoeverre, middels de geoffreerde midoffice applicatie(s) geautomatiseerd beslissingen kunnen worden genomen, zoals het (voorlopig) toekennen van vergunningen en dergelijke. Geef ten slotte aan in hoeverre gebruik kan worden gemaakt van (open) standaarden zoals BPEL, BPMN, en dergelijke. Beschrijf ten slotte ook de mogelijkheden voor het uitwisselen van procesmodellen met andere gemeenten (denk bijvoorbeeld aan importen exportfunctionaliteit, bijbehorende bestandsformaten en dergelijke).

V42

Translatie en transformatie Beschrijf de mogelijkheden met betrekking tot translatie (vertalen van de syntax) en transformatie (vertalen van de semantiek) van berichten en geef aan of, en zo ja hoe, hierbij validatie mogelijk is. Beschrijf bovendien de manier waarop mapping mogelijk is, zoals visueel (middels drag-and-drop) als middels scripts en dergelijke. Geef ten slotte aan welke standaarden gebruikt kunnen worden (zoals XSLT) en geef aan of, en zo ja welke, methoden / talen er naast XML gebruikt kunnen worden (bijvoorbeeld MIME voor attachments).

V43

* Routering en queueing Beschrijf de functionaliteiten op het gebied van synchrone en asynchrone (technische) communicatie tussen applicaties en tussen organisaties. Denk hierbij bijvoorbeeld aan routering gebaseerd op de inhoud van berichten, store-and-forward, fire-and-forget, request-reply, publish-subscribe, multicast, guaranteed delivery, Quality of Service (QoS) en dergelijke. Geef aan hoeverre er in de geoffreerde oplossing sprake is van een centrale broker of van een decentrale ESB-architectuur (Enterprise Service Bus of dienstenbus). Beschrijf bovendien in hoeverre webservice standaarden zoals WSI, SOAP en WSDL, maar ook WS Adressing, WS Security, WS Reliable Messaging en dergelijke worden ondersteund.

V44

Datadistributie Geef aan of, en zo ja hoe, de geoffreerde broker ondersteuning kan bieden voor zogeheten datadistributie: het distribueren van (authentieke en andere) gegevens tussen verschillende backoffice applicaties (zoals persoonsgegevens uit het GBA,


57


maar ook gegevens over gebouwen en percelen uit andere authentieke bronsystemen) ten behoeve van het (in)voeren van authentieke basisregistraties. Beschrijf, indien van toepassing, de mogelijkheden dienaangaande. Denk hierbij onder meer aan de rol van de broker, het gegevensmagazijn, (synchronisatie)adapters, het gebruik van relevante (open) standaarden (zoals STUF) en dergelijke. Beschrijf ten slotte hoe de eventuele functionaliteit op dit gebied zich verhoudt tot een zogeheten datadistributiesysteem of ‘backoffice broker’. 5.5.2 Adapters Bij koppelingen met applicaties wordt onderscheid gemaakt tussen synchronisatie- (voor synchronisatie van gegevens uit een applicatie met het gegevensmagazijn), transactie- (voor het wegschrijven van gegevens in een applicatie) en statusadapters (voor het teruggeven van de status van zaken zoals aanvragen, meldingen en dergelijke vanuit een applicatie naar het zakenmagazijn). V45

* Technische adapters Beschrijf de meegeleverde generieke (technologie)adapters, inclusief een lijst van de ondersteunde versies van de betreffende systemen. Denk hierbij aan databases, XML en dergelijke, maar ook ftp, smtp, http, webservices (WS *), ebMS, COM+, JMS en dergelijke. Onderscheid hier de ondersteunde versies, alsmede de functionaliteit van de adapters (zoals het onderscheid tussen lezen en schrijven, ondersteunde functies, bidirectionaliteit, parameterisering en dergelijke), inclusief een beschrijving met welke geoffreerde appliatie(s) zij koppelen.

V46

* Top-7 adapters (transactie) Beschrijf de meegeleverde gemeentespecifieke transactieadapters voor het koppelen met / aan de applicaties die relevant zijn voor de top-7 gemeentelijke producten (zie ook bijlage 8.9). Geef hierbij steeds de ondersteunde versies van de betreffende applicaties en de functionaliteiten van de betreffende adapters. Besteed hierbij onder meer aandacht aan de manier waarop gekoppeld wordt (bijvoorbeeld API, database via een tussentabel, rechtstreeks of anderszins -, webservices en dergelijke), het onderscheid tussen lezen en schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke. Geef hierbij ten slotte ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor GBA-uittreksels) of dat zij ook voor andere gemeentelijke producten kunnen worden ingezet (bijvoorbeeld of een adapter naar een bepaalde GBA-applicatie kan worden ingezet ten behoeve van meer dan één GBA-gerelateerd product). NB1: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.9), op basis van de relevantie van de adapters per gemeente. NB2: één of meer van deze adapters kunnen in een eventuele PoC worden geverifieerd.

V47

Top-7 adapters (synchronisatie) Beschrijf de meegeleverde gemeentespecifieke synchronisatieadapters voor het koppelen met / aan de applicaties die relevant zijn voor de top-7 gemeentelijke producten (zie ook bijlage 8.9). Geef hierbij steeds de ondersteunde versies van de


58


betreffende applicaties en de functionaliteiten van de betreffende adapters. Denk hierbij met name aan database views, technieken als ‘Oracle streaming’, het omgaan met zogeheten diakrieten,synchronisatie op basis van delta’s (uitsluitend wijzigingen doorgeven in plaats van als batch), het gebruik van (open) standaarden (zoals STUF) en dergelijke. Besteed bovendien aandacht aan de manier waarop gekoppeld wordt (bijvoorbeeld API, database - via een tussentabel, rechtstreeks of anderszins -, webservices en dergelijke), het onderscheid tussen lezen en schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke. Geef hierbij ten slotte ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor GBA-uittreksels) of dat zij ook voor andere gemeentelijke producten kunnen worden ingezet (bijvoorbeeld of een adapter naar een bepaalde GBA-applicatie kan worden ingezet ten behoeve van meer dan één GBA-gerelateerd product). NB1 beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.9), op basis van de relevantie van de adapters per gemeente. NB2: één of meer van deze adapters kunnen in een eventuele PoC worden geverifieerd. V48

Top-7 adapters (status) Beschrijf de meegeleverde gemeentespecifieke statusadapters voor het koppelen met / aan de applicaties die relevant zijn voor de top-7 gemeentelijke producten (zie ook bijlage 8.9). Geef hierbij steeds de ondersteunde versies van de betreffende applicaties en de functionaliteiten van de betreffende adapters. Besteed hierbij onder meer aandacht aan de manier waarop gekoppeld wordt (bijvoorbeeld API, database - via een tussentabel, rechtstreeks of anderszins -, webservices en dergelijke), het onderscheid tussen lezen en schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke. Geef hierbij ten slotte ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor GBA-uittreksels) of dat zij ook voor andere gemeentelijke producten kunnen worden ingezet (bijvoorbeeld of een adapter naar een bepaalde GBA-applicatie kan worden ingezet ten behoeve van meer dan één GBA-gerelateerd product). NB1: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.9), op basis van de relevantie van de adapters per gemeente. NB2: één of meer van deze adapters kunnen in een eventuele PoC worden geverifieerd.

V49

* Overige adapters (transactie) Geef een lijst van overige transactieadapters naar (gemeente)specifieke applicaties (voor zover deze geen betrekking hebben op de top-7 producten zoals genoemd in bijlage 8.12). Geef ook hierbij steeds de ondersteunde versies van de betreffende applicaties en de functionaliteiten van de betreffende adapters. Besteed hierbij onder meer aandacht aan de manier waarop gekoppeld wordt (bijvoorbeeld API, database via een tussentabel, rechtstreeks of anderszins -, webservices en dergelijke), het onderscheid tussen lezen en schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke. Geef hierbij ten slotte ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor GBA-uittreksels) of dat zij ook voor andere gemeentelijke producten kunnen worden


59


ingezet (bijvoorbeeld of een adapter naar een bepaalde GBA-applicatie kan worden ingezet ten behoeve van meer dan één GBA-gerelateerd product). NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.9), op basis van de relevantie van de adapters per gemeente. V50

Overige adapters (synchronisatie en status) Geef een lijst van overige synchronisatieen statusadapters naar (gemeente)specifieke applicaties (voor zover deze geen betrekking hebben op de top-7 producten zoals genoemd in bijlage 8.9). Geef ook hierbij steeds de ondersteunde versies van de betreffende applicaties en de functionaliteiten van de betreffende adapters. Denk hierbij met name aan database views, technieken als ‘Oracle streaming’, het omgaan met zogeheten diakrieten en synchronisatie op basis van delta’s (uitsluitend wijzigingen doorgeven in plaats van als batch), het gebruik van (open) standaarden (zoals STUF) en dergelijke. Besteed hierbij bovendien specifieke aandacht aan de synchronisatie van geografische gegevens. Beschrijf de manier waarop gekoppeld wordt (bijvoorbeeld API, database - via een tussentabel, rechtstreeks of anderszins -, webservices en dergelijke), het onderscheid tussen lezen en schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke. Geef hierbij ten slotte ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor GBA-uittreksels) of dat zij ook voor andere gemeentelijke producten kunnen worden ingezet (bijvoorbeeld of een adapter naar een bepaalde GBA-applicatie kan worden ingezet ten behoeve van meer dan één GBA-gerelateerd product). NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.9), op basis van de relevantie van de adapters per gemeente.

V51

Koppeling met externe systemen (Nederlandse overheid) Beschrijf de mogelijkheden van de geoffreerde applicatie(s) om te kunnen koppelen met externe systemen, bijvoorbeeld met partijen zoals in de SUWI-keten en voor het gebruik van landelijke administraties zoals de LRD. Ga hierbij in ieder geval expliciet in op de mogelijkheden tot koppeling met de E-formulierenmachine van ICTU, het Digitaal Bouwloket van VROM, de Persoonlijke Internetpagina van ICTU, het Bedrijvenloket van EZ / KvK en het landelijke stelsel van basisregistraties.

V52

Product/dienstencatalogus Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezige 3P PDC. Geef hierbij aan in hoeverre een 3P PDC gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P PDC. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke.


60


Maak bij de beantwoording van deze vraag onderscheid tussen functionaliteit voor de klanten (gebruik) en medewerker (beheer) en geef aan welke gegevens, processen, autorisaties (rechten en rollen) en dergelijke kunnen worden gedeeld met de Midoffice Suite (frontoffice, klantcontactcentrum en broker). Geef aan of, en zo ja hoe, informatie uit en de uitkomst van het zoeken in de PDC gebruikt kan worden in formulieren (zoals voor prefill), vraaggeleiding en dergelijke. Zie voor de PDC’s van de verschillende gemeenten bijlage 8.10. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.10 genoemde) PDC’s kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.10), op basis van de relevantie van de adapters per gemeente. V53

Content management Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezig 3P web content management systemen (CMS). Beschrijf hierbij in hoeverre een 3P CMS gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P CMS. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen, autorisaties (rechten en rollen) en dergelijke kunnen worden gedeeld met de Midoffice Suite (frontoffice, klantcontactcentrum en broker). Zie voor de CMS’en van de verschillende gemeenten bijlage 8.10. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.10 genoemde) CMS’en kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.10), op basis van de relevantie van de adapters per gemeente.

V54

Geo-informatie Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezig 3P geo-informatiesysteem (GIS). Beschrijf hierbij in hoeverre een 3P GIS gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P GIS. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak hierbij onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen,


61


autorisaties (rechten en rollen), kaartlagen en dergelijke kunnen worden gedeeld met de verschillende onderdelen van de Midoffice Suite zoals frontoffice (webintake, ‘Mijn Gemeente’ en dergelijke), klantcontactcentrum en broker. Beschrijf of gegevens uit het GIS kunnen worden gebruikt voor bijvoorbeeld prefill in formulieren en/of hoe vanuit een formulier een kaart kan worden weergegeven en andersom. Zie voor de GIS applicaties van de verschillende gemeenten bijlage 8.10. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.10 genoemde) GIS applicaties kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.10), op basis van de relevantie van de adapters per gemeente. V55

* Document management Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezig 3P document management systeem (DMS). Beschrijf hierbij in hoeverre een 3P DMS gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P DMS. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen, autorisaties (rechten en rollen) en dergelijke kunnen worden gedeeld met de Midoffice Suite (frontoffice, klantcontactcentrum en broker). Zie voor de DMS’en van de verschillende gemeenten bijlage 8.10. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.10 genoemde) DMS’en kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.10), op basis van de relevantie van de adapters per gemeente.

V56

Identity management Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezig 3P identity management tool (directory servers, identity servers en dergelijke). Beschrijf hierbij in hoeverre een 3P identity management tool gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P tool voor identity management. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen, autorisaties


62


(rechten en rollen) en dergelijke kunnen worden gedeeld met de Midoffice Suite (frontoffice, klantcontactcentrum en broker). Zie voor de identity management tools van de verschillende gemeenten bijlage 8.11. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.11 genoemde) identity management tools kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlage 8.11), op basis van de relevantie van de adapters per gemeente. V57

Relatiebeheer Geef aan hoe u een koppeling realiseert met een bij een gemeente reeds aanwezig 3P relatiebeheer (CRM) applicatie. Beschrijf hierbij in hoeverre een 3P CRM applicatie kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen fronten midoffice applicaties. Beschrijf de technische en functionele eigenschappen van de adapters die integratie mogelijk maken tussen de Midoffice Suite en de bij een gemeente aanwezige 3P CRM applicatie. Besteed onder meer aandacht aan de functionaliteiten (bijvoorbeeld lezen / schrijven, ondersteunde functies, bi-directionaliteit, parameterisering en dergelijke) alsook aan de gebruikte technieken (directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCC-medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen, autorisaties (rechten en rollen) en dergelijke kunnen worden gedeeld met de Midoffice Suite (frontoffice, klantcontactcentrum en broker). Zie voor de CRM applicaties van de verschillende gemeenten bijlage 8.10. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.10 genoemde) CRM applicaties kunt integreren en geef aan welke dit zijn. NB: beoordeling vindt plaats op basis van de relevantie van de adapters per gemeente.

V58

Ontwikkeling adapters Beschrijf de adapter SDK en ondersteunende tools. Geef aan welke methoden, technieken en standaarden gebruikt worden bij het ontwikkelen van adapters en beschrijf of en in welke mate adapters open zijn. Denk hierbij aan het delen van adapters met andere gemeenten, aanpasbaarheid van adapters en dergelijke. Geef bovendien aan welke open standaarden in de ruimste zin des woords (denk aan webservices, koppelvlakken, bestandsindeling, databaseformaten en dergelijke) inclusief eventuele versies de geoffreerde midoffice applicatie(s) ondersteunt.

5.5.3 Technische architectuur De vragen in deze paragraaf hebben betrekking op de technische architectuur van de Midoffice Suite en de geoffreerde applicatie(s). Indien van toepassing wordt u geacht om elk van deze vragen afzonderlijk te beantwoorden voor ieder onderdeel van de Midoffice Suite (frontoffice, klantcontactcentrum inclusief DMS en broker) en/of iedere geoffreerde applicatie.


63


V59

* Clientside architectuur: eindgebruikers Geef aan welke browsers en andere clientside technologieën worden ondersteund voor klanten en FO/KCC-medewerkers. Denk hierbij onder meer aan (de presentatie van) de website, elektronische formulieren, geo-informatie, portals, document management systemen, statusvolging, generieke applicaties, het klantcontactcentrum en dergelijke. Onderscheid hierbij steeds verschillende rollen, zoals klant en FO/KCC-medewerker. NB: een zo browser- en platformonafhankelijk mogelijk gedrag heeft de voorkeur. Denk hierbij aan browsers met- en zonder plug-ins en platforms zoals MS Windows, Linux, Macintosh, HP-UX en Solaris en dergelijke (inclusief vermelding van versies). Geef bovendien voor elk van deze platforms de betreffende beperkingen aan. Denk hierbij aan restricties voor clientside scripting en dergelijke, voor bepaalde functionaliteiten vereiste versies, browser plug-ins, verlaagde veiligheidsinstellingen en dergelijke. Geef aan of, en zo ja welke, beperkingen in functionaliteiten en/of aandachtspunten er zijn indien de website volgens de Drempels Weg normen wordt aangeboden (voorkeur is automatische ondersteuning van het voldoen aan de Drempels Weg normen voor de klant, zoals automatische generatie van een Drempels Weg versie van een formulier).

V60

Clientside architectuur: power users Geef aan welke browsers en andere clientside technologieën (zoals een ‘fat client’) voor de overige rollen - zoals formulierontwikkelaar (inhoud: intelligentie, logica en dergelijke), formulierontwerper (vorm), procesontwikkelaar, technisch beheerder en functioneel beheerder - worden ondersteund voor MS Windows, Linux, Macintosh, HP-UX en Solaris platforms en dergelijke, inclusief vermelding van versies. Geef bovendien voor elk van deze platforms de betreffende beperkingen aan. Denk hierbij onder meer aan restricties inzake resolutie, WYSIWYG-editing bij het ontwerpen van formulieren en processen, schermen fontgrootte en dergelijke.

V61

* Serverside architectuur: inrichting en samenhang Geef schematisch aan hoe de verschillende onderdelen (te weten FO, KCC en broker), componenten (zoals webintake, vraaggeleiding, gegevens- en zakenmagazijn, DMS, CRM, WfM, broker, en dergelijke) en applicaties zich zowel functioneel als technisch tot elkaar verhouden. Denk bijvoorbeeld aan servergebruik, communicatieprotocollen, gedeelde databases en dergelijke, alsmede aan mogelijke plaatsen voor firewalls. Beschrijf de samenhang tussen die componenten voor wat betreft platforms (zowel hardware- als serverplatforms zoals operating systemen, webservers, applicatieservers en databaseservers), databases en dergelijke, geef aan wat de eisen en mogelijkheden zijn en, indien van toepassing, welke combinatie(s) uw voorkeur hebben. Denk hierbij aan platforms zoals MS Windows, Linux, Macintosh, HP-UX en Solaris en dergelijke, alsmede aan databases zoals Oracle, MS SQL, MySQL en dergelijke. Geef bovendien aan in hoeverre deze componenten gebruik maken van dezelfde technieken, zoals voor wat betreft componentmodel (.Net, Java en dergelijke), programmeer- en scripttalen en dergelijke. Beschrijf de mate waarin de Ontwikkel- Test-, Acceptatie- en Productieomgevingen (OTAP) samenhangen dan wel gescheiden zijn (zoals gescheiden databases) en geef


64


aan hoe de verschillende elementen van de ene omgeving worden overgezet naar de andere. Denk hierbij aan verschillende soorten wijzigingen, zoals applicaties, adapters, processen, formulieren en dergelijke. Beschrijf bovendien het transitieproces tussen de omgevingen, alsmede of, en zo ja hoe, toepassen van het OTAP principe verenigbaar is met het terugdringen van het aantal (fysieke) servers. NB: beoordeling vindt plaats per gemeente, mede op basis van reeds aanwezige kennis, ervaring en langlopende contracten met betrekking tot platforms, componentmodellen en applicaties. V62

* Beveiliging Geef aan hoe door de gemeenten gezorgd kan worden voor een adequate beveiliging van zowel front-, mid- als backoffice. Beschrijf de mogelijkheden en beperkingen met betrekking tot beveiliging. Denk hierbij aan databeveiliging (van ingevulde gegevens), communicatiebeveiliging (zoals SSL tussen onderdelen en het gebruik van standaarden zoals WS Security, SAML2 en dergelijke), gegevensintegriteit en vertrouwelijkeheid (inclusief encryptie en onweerlegbaarheid), netwerkbeveiliging (zoals de plaatsing van firewalls) en dergelijke. Denk echter ook aan niet-technische aspecten zoals authenticatie en autorisatie (rechten en rollen op verschillende aspecten, niveaus en dergelijke). Geef hierbij bovendien aan of en hoe een fysieke en logische scheiding van frontoffice (webintake), KCC (gegevens- en zakenmagazijn), broker en backoffices mogelijk is en hoe rechten en rollen worden gedefinieerd over verschillende systemen heen. Geef aan hoe de gegevensintegriteit wordt gewaarborgd van gegevens in en tussen componenten van de Midoffice Suite. Geef ten slotte aan hoe door de gemeenten gezorgd kan worden voor een adequate beveiliging in fronten midoffice zodat voldaan wordt aan de verschillende relevante weten regelgevingen zoals WBP, Archiefwet en dergelijke. Denk hierbij onder meer aan ReMANO, DSP’s en de ‘basis selectielijst’. Beschrijf tevens de mogelijkheden ten aanzien van signalering en logging bij misbruik en maak hierbij, indien relevant, een onderscheid tussen de verschillende componenten van de Midoffice Suite.

V63

Schaalbaarheid Geef aan of 250 concurrent users de aangeboden applicatie(s) met een acceptabele performance kunnen bedienen. Doe hetzelfde voor een situatie waarbij ook gebruik wordt gemaakt van de CRM- en DMS functionaliteit en dergelijke. Geef in dit kader ook uw definitie van concurrent users. NB: 250 concurrent users is hier gedefinieerd als een mix van ingelogde klanten (die allen een formulier aan het invullen zijn, inzage hebben in hun gegevens en dergelijke) en FO/KCC-medewerkers. Geef een beschrijving van de mogelijke technieken om zowel horizontale als verticale schaalbaarheid te bereiken. Denk onder meer aan caching, clustering, load-balancing en dergelijke. Geef ook aan of het verhogen van de schaalbaarheid voor de gebruikers transparant is. Beschrijf, indien van toepassing, de (technische) maxima van aantallen openstaande c.q. afgesloten objecten, processen, formulieren en dossiers, de maximale omvang van attachments en dergelijke. Geef een in uw ogen meest adequate schatting van het aantal concurrent users waarmee, op basis van de in paragraaf 1.1 genoemde inwonertallen, rekening gehouden dient te worden en beschrijf of, en zo ja hoe, de aangeboden applicatie(s) hierin voorzien. Geeft ten slotte een indicatie, op basis van


65


diezelfde inwonertallen, van de omvang van het systeem door de tijd heen (zoals in termen van het aantal zaken in behandeling, de omvang van het gegevensmagazijn en dergelijke, alsmede van de historie in het systeem log) en beschrijf of, en zo ja hoe, de aangeboden applicatie(s) hierin voorzien. gEef aan wat volgens u een acceptabele performance is. V64

Beschikbaarheid Beschrijf de technische architectuur (zoals aantallen servers, fail-over en dergelijke) die nodig is voor een 24x7 beschikbaarheidpercentage van 99,0% van de voor de klant beschikbare delen van de Midoffice Suite, uitgaande van ‘unattended operation’ buiten kantooruren. Doe hetzelfde voor een beschikbaarheidpercentage van 99,9%.

5.5.4 Overig V65

Additionele functionaliteiten Hier kunt u additionele (hierboven niet genoemde) in het kader van deze paragraaf 5.5 relevante functionaliteiten van de aangeboden applicatie(s) beschrijven.


66


5.6

Vragen Midoffice Suite: gebruiksgemak en beheer

5.6.1 Gebruiksgemak De vragen in deze paragraaf 5.6.1 hebben betrekking op het gebruiksgemak van de Midoffice Suite en de geoffreerde applicatie(s). Indien van toepassing wordt u geacht om elk van deze vragen afzonderlijk te beantwoorden voor ieder onderdeel van de Midoffice Suite (frontoffice, klantcontactcentrum inclusief DMS en broker) en/of iedere geoffreerde applicatie. V66

* Gebruiksgemak en toegankelijkheid: klant Beschrijf welke faciliteiten er beschikbaar zijn voor gebruik door, en ondersteuning daarbij van, de klanten. Denk hier bijvoorbeeld aan wizard-achtige presentatie, prefill, logica (validaties) en intelligentie (routering) bij formulieren, alsmede aan zaken als consistentie van de webinterface, navigatie en menu’s, schermindelingen (inclusief minimale respectievelijk maximale mogelijke schermgroottes), toetsenbordoriëntatie (zoals ctrl-functies, shortcuts, en tabgebruik), contextgevoelige (on-line) helpfunctie en dergelijke. Geef hier ter illustratie een overzicht van de acties die een klant moet uitvoeren om een formulier in te vullen (inclusief screenshots).

V67

* Gebruiksgemak en toegankelijkheid: FO/KCC-medewerker Beschrijf welke faciliteiten er beschikbaar zijn voor gebruik door, en ondersteuning daarbij van, de FO/KCC-medewerkers. Geef hier ter illustratie een overzicht van de acties die een FO/KCC-medewerker moet uitvoeren om een mutatie door te voeren in een klantdossier (inclusief screenshots). Denk hierbij aan toegang met behulp van webbrowser en/of fat client, grafische en/of command line interface, intuïtiviteit en consistentie van interface, navigatie en menu’s, minimale respectievelijk maximale mogelijke schermgroottes, toetsenbordoriëntatie (ctrl-functies, shortcuts, tab en dergelijke), documentatie, contextgevoelige (on-line) helpfunctie, invoervalidaties, vereiste of benodigde cursussen en dergelijke. Maak hierbij, indien relevant, een onderscheid tussen de verschillende onderdelen van de Midoffice Suite waar FO/KCC-medewerker mee te maken hebben, zoals het invullen van een formulier namens een klant en andere frontoffice taken, alsmede statusvolging en andere KCC taken (inclusief CRM, DMS en WfM).

V68

Gebruiksgemak en toegankelijkheid: functioneel en technisch beheer Beschrijf welke faciliteiten er beschikbaar zijn voor gebruik door, en ondersteuning daarbij van, functioneel en technisch beheerders. Denk hierbij aan toegang met behulp van webbrowser en/of fat client, grafische en/of command line interface, intuïtiviteit en consistentie van de interface, navigatie en menu’s, toetsenbordoriëntatie (tab, ctrlfuncties, shortcuts en dergelijke), documentatie, contextgevoelige (on-line) helpfunctie en dergelijke.

V69

Gebruiksgemak en toegankelijkheid: formulieren procesontwikkelaars Beschrijf welke faciliteiten er beschikbaar zijn voor gebruik door, en ondersteuning daarbij van, formulierontwikkelaars (inhoud) en -ontwerpers (vorm), alsmede voor procesontwikkelaars (zowel A2A als A2P). Denk hierbij aan toegang met behulp van


67


webbrowser en/of fat client, grafische en/of command line interface, intuïtiviteit en consistentie van de interface, navigatie en menu’s, toetsenbordoriëntatie (ctrl-functies, shortcuts, tab en dergelijke), documentatie, contextgevoelige (on-line) helpfunctie en dergelijke. V70

Lokalisatie Beschrijf op welke manier rekening wordt gehouden met meertaligheid (denk onder meer aan diakrieten, maar ook aan vertalingen van formulieren) en met andere landen (denk aan landafhankelijke validaties, maar ook authenticatie van niet-ingezetenen en zaken als valuta, datumweergave en dergelijke). Geef hierbij ook de beperkingen en randvoorwaarden.

V71

Aanpasbaarheid look & feel Beschrijf de mogelijkheden waarop de applicatie(s) waar de klant mee in aanraking komt, aangepast kunnen worden aan de eigen huisstijl. Denk hier bijvoorbeeld aan (CSS) stylesheets, kleurgebruik, gebruikte figuren en dergelijke. Doe hetzelfde voor de applicatie(s) waar de klant niet direct mee in aanraking komt.

5.6.2 Beheer De vragen in deze paragraaf 5.6.2 hebben betrekking op het beheer van de Midoffice Suite en de geoffreerde applicatie(s). Indien van toepassing wordt u geacht om elk van deze vragen afzonderlijk te beantwoorden voor ieder onderdeel van de Midoffice Suite (frontoffice, klantcontactcentrum inclusief DMS en broker) en/of iedere geoffreerde applicatie. V72

* Autorisatie Beschrijf de mogelijkheden ten aanzien van autorisatie en de te gebruiken rechten- en rollen modellen binnen de geoffreerde applicatie(s). Denk hierbij onder meer aan de verschillende gebruikersgroepen (zoals burgers, bedrijven en verschillende groepen medewerkers), autorisatieniveaus (zoals lezen, toevoegen, wijzigen en/of verwijderen van gegevens), objecten waaraan rechten kunnen worden toegewezen (bijvoorbeeld processen, dossiers, klanten, velden en dergelijke) alsmede aan de overerving van rechten en dergelijke. Betrek hierbij tevens zogeheten Access Control Lists (ACL’s oftewel autorisatiematrices). Beschrijf de granulariteit en flexibiliteit met betrekking tot autorisatie. Beschrijf hier ook de al dan niet grafische interfaces (inclusief overzichten van gebruikers per groep, effectieve gebruikersrechten en dergelijke). Geef aan of, en zo ja in welke mate, er de mogelijkheid bestaat om beschikbaarheid vast te leggen (per medewerker, per rol, per groep en dergelijke) c.q. of, en zo ja hoe, hiertoe wordt gekoppeld met of geïmporteerd uit HRM applicaties. Beschrijf hierbij ook of, en zo ja hoe, er een ‘multi-domein’ model kan worden ingericht, waarbinnen rechten en rollen gedelegeerd kunnen worden. Beschrijf of, en zo ja in hoeverre, de betreffende functionaliteit beschikbaar is per onderdeel (zoals frontoffice, klantcontactcentrum en broker), per applicatie en per functionaliteit en in hoeverre over de onderdelen / applicaties / functionaliteiten heen.


68


Beschrijf in hoeverre en met welke 3P identity management tools (directory servers, identity servers en dergelijke), inclusief versienummers, geïntegreerd kan worden. Geef hierbij aan of er sprake is van bepaalde beperkingen. Geef hierbij ook aan in hoeverre het autorisatiemodel en de genoemde functionaliteiten gelden per component (frontoffice, midoffice en dergelijke) en in hoeverre over componenten heen. Betrek hierbij in ieder geval het rechten- en rollenmodel Beschrijf ten slotte de mogelijkheden voor het gebruik van digitale handtekeningen en PKI, zowel voor formulieren als documenten. Denk in dat kader ook aan de eventuele mogelijkheden om producten volledig elektronisch te kunnen leveren (bijvoorbeeld GBA-uittreksels), waarbij de integriteit en echtheid van wordt gewaarborgd met een echtheidskeurmerk (zoals ten behoeve van scholen, woningcorporaties en dergelijke). V73

* Functioneel en technisch beheer Beschrijf de hulpmiddelen voor en mogelijkheden met betrekking tot functioneel en technisch beheer van de verschillende onderdelen (frontoffice, klantcontactcentrum en broker), applicaties en functionaliteiten van de Midoffice Suite. Denk hierbij ook aan zaken als beheerinterface, scripting, koppelingen met 1P en 3P beheer-, rapportage- en analysetools en dergelijke. NB: dit betreft de kracht en breedte van de hulpmiddelen, niet het gebruiksgemak ervan. Geef ten slotte aan hoeveel FTE een middelgrote gemeente (met een inwonertal tussen de 50.000 en 100.000) structureel nodig heeft om de Midoffice Suite te beheren. Splits uw antwoord uit in zowel functioneel als technisch beheer per onderdeel (frontoffice, klantcontactcentrum en broker). NB: beoordeling vindt plaats per gemeente, mede op basis van reeds aanwezige kennis, ervaring en langlopende contracten met betrekking tot platforms, componentmodellen en applicaties.

5.6.3 Managementrapportage Deze vraag heeft betrekking op managementsrapportage rondom de Midoffice Suite en de geoffreerde applicatie(s). Indien van toepassing wordt u geacht om deze vraag voor ieder onderdeel van de Midoffice Suite (frontoffice, klantcontactcentrum inclusief DMS en broker) en/of iedere geoffreerde applicatie afzonderlijk te beantwoorden. V74

Managementinformatie Beschrijf de mogelijkheden voor wat betreft (management)rapportages voor FO/KCC functies en geef een overzicht van beschikbare standaardrapportages, zoals aanvragen per product(groep), per periode, per status, per medewerker, per rol, per afdeling, per doorlooptijd en dergelijke. Denk hierbij ook aan zaken als doorlooptijden, bottlenecks en dergelijke en geef aan of en hoe dergelijke rapportages gebruikt kunnen worden ter bewaking van SLA’s en dergelijke. Denk ten slotte nog aan overzichten als aantallen actieve en afgehandelde processen en zaken, bewerkingstaken per persoon, per stap en dergelijke en geef aan welke mogelijkheden er zijn voor wat betreft voorspellingen ten aanzien van workload en output.


69


Onderscheid bij de beantwoording van deze vraag standaardrapportages en complexe ad-hoc rapportages / queries die medewerkers zelf kunnen samenstellen. Beschrijf of, en zo ja in hoeverre, de betreffende functionaliteit beschikbaar is per onderdeel (zoals frontoffice, klantcontactcentrum en broker), per applicatie en per component en in hoeverre over de onderdelen / applicaties / functionaliteiten heen. Onderscheid tevens real-time informatieverschaffing (zoals in het kader van BAM) en offline rapportages. Beschrijf in dat kader ook de modelleer- en beheervoorzieningen ten aanzien van de onderliggende database(s). Besteedt hierbij, indien van toepassing, ook aandacht aan het gegevensmagazijn, een eventueel datawarehouse en dergelijke. Geef ten slotte aan welke 3P (standaard)applicaties (zoals Cognos, Crystal Report en dergelijke) hiervoor kunnen worden gebruikt, onder vermelding van versienummers en dergelijke. Beschrijf ten slotte de eventueel reeds beschikbare standaardrapportages via deze applicaties. 5.6.4 Integratie V75

* Functionele architectuur, inrichting en samenhang Beschrijf de functionele architectuur van de geoffreerde Midoffice Suite, inclusief plaatsing van en verhouding tussen de functionele componenten zoals webintake, broker, gegevens- en zakenmagazijn, document management en dergelijke. Geef aan in hoeverre deze componenten gebruik maken van gedeelde repositories, autorisaties (zoals groepen, rechten en rollen, single-sign-on en dergelijke), beheer- en procestools en dergelijke. Beschrijf de relatie tussen de genoemde functionele componenten en de elementen van de technische architectuur.

V76

* Beheerintegratie Beschrijf de integratie tussen de verschillende onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) voor wat betreft gemeenschappelijke authenticatie en autorisatie, rechten en rollen, groepen, domeinen en dergelijke. Geef hierbij ook aan of, en zo ja in hoeverre, ontwerp, beheer, gebruik en monitoring van deze rechten door dezelfde componenten / tools / interfaces kan worden gerealiseerd.

V77

* Procesintegratie Beschrijf de integratie tussen de verschillende onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) voor wat betreft doorlopende processen (dat wil zeggen vanuit het frontoffice naar het backoffice). Geef hierbij ook aan of, en zo ja in hoeverre, ontwerp, beheer, executie en monitoring van frontoffice workflow, klantcontactcentrum workflow (inclusief documenten case management) en broker workflow (BPM / procesorkestratie) door dezelfde componenten / tools / interfaces kan worden gerealiseerd.

V78

Gegevensintegratie Beschrijf de integratie tussen de verschillende onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) voor wat betreft gedeelde gegevens zoals records / velden, documenten, content, geo-informatie en dergelijke. Geef hierbij ook


70


aan of, en zo ja in hoeverre, ontwerp, beheer, bewerking en inkijk van / rapportage op deze gegevens door dezelfde componenten / tools / interfaces kan worden gerealiseerd. V79

Validatie integratie Beschrijf de integratie tussen de verschillende onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) voor wat betreft validaties en business rules. Denk hierbij aan meervoudige (in front-, mid- en backoffice) executie (door business rules engines) en enkelvoudige definitie, opslag (in repositories) en beheer daarvan. Bij voorkeur zijn deze validaties respectievelijk business logica aldus identiek over alle applicaties (dus voor het invullen van een formulier door een klant en een FO/KCC-medewerker - zowel clientside als serverside - voor de ontwikkeling van formulieren, voor de koppeling met backoffice applicaties, voor batch imports; voor het gebruik bij workflow management en dergelijke).


71


5.7

Eisen en vragen Initiële implementatie

5.7.1 Inleiding De onderhavige aanbesteding omvat de levering van een zogeheten Midoffice Suite, alsmede de Initiële implementatie daarvan. Deze inleidende paragraaf beschrijft de werkzaamheden in het kader van die Initiële implementatie. Het betreft een generieke implementatieopdracht; als een individuele gemeente daarvan afwijkt, wordt dit in de desbetreffende gemeentespecifieke bijlage beschreven. Naar alle waarschijnlijkheid zullen alle gemeenten die in het Consortium vertegenwoordigd zijn (vrijwel) de volledige Midoffice Suite aanbesteden. Elk van de aan het Consortium deelnemende gemeenten heeft echter het recht om af te zien van de gunning van één of meer van de onderdelen en/of componenten van de Midoffice Suite. De Initiële implementatie bestaat uit: -

De installatie van de Midoffice Suite

-

De basisimplementatie van de Midoffice Suite

-

De inrichting van de eerste zeven gemeentelijke producten

Fasering Nadat een gemeente, eventueel na het uitvoeren van een Proof of Concept, ertoe besluit om de onderhavige opdracht te gunnen, kan de Initiële implementatiepartner bij die gemeente met de Initiële implementatie beginnen. Dit betreft de implementatie van de eerste zeven producten. Afhankelijk van de uitkomst van de aanbesteding worden aan een Inschrijver geen, één of meerdere (tot een maximum van het aantal gemeenten in het Consortium) opdrachten gegund. Uitgaande van gunning van meerdere opdrachten aan dezelfde Inschrijver, zullen de Initiële implementaties door die Inschrijver gefaseerd plaatsvinden. In de eerste fase zal bij voorkeur één gemeente worden geïmplementeerd (twee gemeenten is in deze fase het maximum). Al naar gelang het succes van deze eerste Initiële implementatie(s), zullen daarna (indien van toepassing) weer één of twee gemeenten volgen. Daarna volgen de eventueel nog resterende gemeenten. Inschrijver dient bij elk van de gemeenten die de onderhavige opdracht aan hem gunnen de Initiële implementatie binnen zes maanden te hebben afgerond, gerekend vanaf het moment dat de betreffende gemeente de opdracht tot Initiële implementatie geeft. Installatie van fronten midoffice De fronten midoffice applicatie(s) moeten hetzij volledig werkend op de productieomgeving van de betreffende gemeente zijn geïnstalleerd, hetzij bij de aanbieder (indien het een ASPoplossing betreft). Tijdens de installatie dient ook de integratie tussen de verschillende onderdelen te worden gerealiseerd. Dit betekent onder andere dat de Midoffice Suite gebruik maakt van één gegevensmagazijn, één zakenmagazijn en één centraal aangestuurde horizontale workflow. Configuratie van software ten behoeve van de integratie tussen fronten midoffice dient in deze fase plaats te vinden.


72


Daarnaast moeten eventuele ondersteunende applicaties zoals een webserver, applicatieserver en/of andere applicaties werkend zijn geïnstalleerd en moet een ontwikkel-, testen acceptatie omgeving zijn ingericht. Basisimplementatie fronten midoffice Na de installatie vindt de basisimplementatie van fronten midoffice plaats. Deze bestaat enerzijds uit de technische configuratie, het inrichten van gebruikers, rechten en rollen en dergelijke, alsmede de integratie tussen fronten midoffice. Ook de basisinrichting van gegevens, processen en functioneel en technisch beheer behoort tot de basisimplementatie. De basis inrichting van gegevens heeft betrekking op het gegevens- en zakenmagazijn en het aansluiten van de product/dienstencatalogus (PDC) en eventuele kennisbomen. Ten behoeve van de FO- en KCC-componenten als webintake, product/dienstencatalogus, zakenmagazijn, gegevensmagazijn en document management behoort ook de migratie van gegevens tot de basisimplementatie. Bij de procesinrichting verdienen de basisstatussen, E-mailnotificaties en het gebruik van DigiD en Ogone speciale aandacht. Tot de basisinrichting van het functioneel en technisch beheer behoren onder meer de faciliteiten voor het ontwerp van de elektronische formulieren. Inrichting eerste zeven gemeentelijke producten De volgende fase in de Initiële implementatie, na de installatie en de basisimplementatie, is de inrichting van de top-7 gemeentelijke producten. Dit zijn de producten: -

Aanvragen GBA-uittreksel

-

Aanvragen binnengemeentelijke verhuizing

-

Aanvragen inzameling grofvuil

-

Afspraak maken

-

Aanvragen lichte bouwvergunning (via Digitaal Bouwloket)

-

Indienen melding openbaar gebied

-

Indienen generiek bezwaarschrift (inclusief WOZ)

Bijlage 8.12 bevat een globale beschrijving van de betreffende producten, terwijl in bijlage 8.9 per product is aangegeven welke backoffice applicaties bij de verschillende gemeenten in het Consortium aan de betreffende producten zijn gerelateerd. Per product dient onder meer aandacht te worden besteed aan het elektronische formulier, de inrichting van het gegevens- en zakenmagazijn, de communicatie met relevante fronten backoffice applicaties en andere systemen, de inrichting van statussen en de mogelijkheid om zogenaamde ‘backoffice-loze’ producten te ontwikkelen en gebruiken. Het inrichten van de elektronische formulieren betreft niet alleen de inhoud en de lay-out, maar ook de routering door de formulieren (intelligentie), validaties (logica), prefill en dergelijke, inclusief de bijbehorende inrichting van het gegevens- en zakenmagazijn.


73


De koppeling met de desbetreffende backoffice applicaties maakt als zodanig dus onderdeel uit van de inrichting van de eerste zeven gemeentelijke producten. Bij koppelingen met het backoffice wordt onderscheid gemaakt tussen synchronisatiekoppelingen (voor synchronisatie van gegevens uit een backoffice applicatie met het gegevensmagazijn), transactiekoppelingen (voor het wegschrijven van gegevens in een backoffice applicatie) en statuskoppelingen (voor het teruggeven van de status van zaken zoals aanvragen, meldingen en dergelijke vanuit een backoffice applicatie naar het zakenmagazijn). De gemeenten in het Consortium hebben de uitdrukkelijke intentie om voor de producten uit de Initiële implementatie naast synchronisatieen statuskoppelingen indien van toepassing ook transactiekoppelingen te realiseren. Volgens het fasemodel elektronische dienstverlening (zie figuur 9) heeft dergelijke transactie integratie betrekking op fase 3. Overigens lenen niet alle gemeentelijke producten zich daadwerkelijk voor elektronische levering (fase 4). Fase Publicatie Fase 0 Papieren formulier

Intake Handmatig (papier) Fase 1 PDF-/Wordformulier Handmatig (papier) Elektronisch Fase 2 Web-/E-formulier Fase 3 Web-/E-formulier

Elektronisch

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

Fase 4 Web-/E-formulier

Elektronisch

Elektronisch

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

Figuur 3: fasemodel elektronische dienstverlening De gewenste transactiekoppelingen zijn koppelingen op applicatieniveau, bij voorkeur op basis van webservices, waarbij de op formulieren ingevulde gegevens volledig automatisch, dus zonder tussenkomst van een medewerker, in de betreffende backoffice applicaties worden ingevoerd met inachtneming van de applicatielogica (business rules of validaties) van die betreffende backoffice applicatie. Inschrijvers hebben een zware inspanningsverplichting om zulks in overleg met de leveranciers van de betreffende backoffice applicaties te realiseren, waarbij de gemeenten verenigd in het Consortium en EGEM hen desgewenst en voor zover nodig kunnen bijstaan, bijvoorbeeld voor het uitoefenen van druk op de leverancier(s) van de betreffende backoffice applicatie(s). Resultaat Initiële implementatie Ten aanzien van de Initiële implementatie gelden de volgende basisvoorwaarden: -

-

Een volledige technische en functionele beschrijving van de Midoffice Suite is door de Initiële implementatiepartner beschikbaar gesteld. Nederlandstalige gebruikershandleidingen voor alle applicaties, functies en rollen (FO/KCC-medewerkers, functioneel beheerders, technische beheerders, ontwikkelaars en dergelijke) zijn beschikbaar gesteld. De Midoffice Suite is ingericht en volledig werkend opgeleverd, inclusief de top-7 producten, volgens de eisen van en in samenwerking met de individuele gemeenten. Het voldoen aan alle functionele Eisen is expliciet aangetoond. Een volledig autorisatiemodel (rechten en rollen) is actief overeenkomstig de situatie bij de individuele gemeenten.


74


De beheeromgeving voor alle aanwezige componenten van de Midoffice Suite (webintake, vraaggeleiding, workflow en dergelijke) is aanwezig. - Authenticatie van medewerkers, aansluitend bij en gebruik makend van de bij de gemeente aanwezige identity management tool is mogelijk (in bijlage 8.11 is voor iedere gemeente aangegeven welke identity management tools worden gebruikt). - De huisstijl van de gemeenten is doorgevoerd in alle componenten van de Midoffice Suite. - De performance en schaalbaarheid van de Midoffice Suite zijn voldoende bewezen. -

Naast de bovengenoemde basisvoorwaarden wordt er een aantal eisen gesteld met betrekking tot de onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker). NB: met klanten van een gemeente worden zowel burgers als bedrijven bedoeld. •

Frontoffice -

-

-

•

De redactieomgeving voor formulieren is ingericht, inclusief autorisatie (rechten en rollen), workflow rondom het maken en aanpassen van formulieren en mogelijkheden om zaken als prefill, intelligentie en logica (validaties) te configureren en te gebruiken. Voor wat betreft validaties dienen zowel singlefield als multifield validatie te zijn geïmplementeerd, inclusief validatie met het gegevens- en/of zakenmagazijn. Een klant kan met behulp van vraaggeleiding naar het juiste formulier worden geleid. De tool voor formulierontwerp is te gebruiken en te testen in respectievelijk een ontwikkelen een testomgeving. Klanten, dat wil zeggen burgers (tenminste via DigiD) en bedrijven (bijvoorbeeld via DigiD voor bedrijven), kunnen zich authenticeren en de formulieren invullen. Later kunnen ze (in ieder geval via het web en via E-mail) de status volgen van hun zaken. Bepaalde daartoe geautoriseerde FO/KCC-medewerkers kunnen namens een klant een formulier invullen en een zaak volgen en afhandelen. Klanten kunnen de gewenste producten elektronisch betalen en de afhandeling van betalingen is ingericht. Een burger kan inloggen op de ‘Mijn loket’ functionaliteit en kan in ieder geval de statussen van zijn/haar persoonlijke aanvragen volgen.

Midoffice -

-

De broker is actief. Alle gekoppelde systemen kunnen informatie overdragen. Er is één gegevensmagazijn gerealiseerd. Hieruit wordt in ieder geval de informatie gehaald ten behoeve van prefill. Een basisinrichting van het zakenmagazijn is gerealiseerd. Naar het zakenmagazijn wordt in ieder geval geschreven: informatie naar aanleiding van ingevulde formulieren, wijzigingen via de beheersinterface van een FO/KCC-medewerker en statusupdates van achterliggende applicaties. FO/KCC-medewerkers kunnen zoeken in het zakenmagazijn. Zoeken is in ieder geval mogelijk op zaak-ID, op omschrijving, op klant-ID en op naam van een klant. Bij klantcontacten kan een FO/KCC-medewerker contactinformatie bijhouden, alsmede eerdere klantcontacten opzoeken. De functionaliteit waarmee een beheerder op eenvoudige wijze generieke applicaties kan inrichten is aanwezig. Een beheeromgeving voor het creëren en beheren van zowel A2A (applicatie) workflow als A2P (menselijke) workflow is aanwezig.


75


DMS -

Het DMS is geïnstalleerd, geconfigureerd en geïntegreerd met de Midoffice Suite. Er is een document repository ingericht. Afhankelijk van de rechten kunnen FO/KCCmedewerkers documenten inzien, bewerken, metadata wijzigen, verwijderen, etc. Alle documenten uit een eventueel reeds aanwezig DMS zijn geconverteerd naar het nieuwe DMS. De autorisatiestructuur (rollen en rechten) voor medewerkers, burgers en bedrijven is volledig ingericht. Postregistratie van ingaande en uitgaande post (papier en E-mail) is mogelijk. Metadatering van documenten en dossiers is mogelijk. Documentinvoer is mogelijk. Er is functionaliteit aanwezig om documenten toe te voegen. Dossiervorming wordt ondersteund, inclusief een koppeling met het zakenmagazijn. Publicatie van documenten en dossiers vanuit het DMS naar het internet is mogelijk volgens het Internet Publicatie Model. Er is een beheeromgeving voor het maken en wijzigen van A2P workflow aanwezig.

In het kader van de Initiële implementatie dienen ook de eerste zeven producten volledig te zijn ingericht. Volledige inrichting wordt daarbij tenminste gezien als: -

-

De productformulieren inclusief logica, validaties en prefill zijn beschikbaar. Inrichting van en koppelingen met het gegevens- en zakenmagazijn zijn gerealiseerd. De A2A (applicatie) workflow en/of A2P (menselijke) workflow processen zijn ingericht. Het automatisch versturen van proactieve én reactieve statusupdates naar de aanvrager is mogelijk. Het doorvoeren van statusweergave én statusupdates in het Midoffice door FO/KCCmedewerkers is mogelijk. Het is mogelijk voor FO/KCC- en DIV-medewerkers om documenten (bijvoorbeeld TIFF of Word files) toe te voegen aan een zaak en op te slaan in een DMS en/of (als verwijzing naar het DMS) in het zakenmagazijn. Koppelingen met de betreffende backoffice applicaties zijn gerealiseerd, zowel voor wat betreft het doorvoeren van transacties als het teruggeven van statussen. Koppeling met andere voor de top-7 producten relevante applicaties zijn gerealiseerd. Koppeling van het gegevensmagazijn met relevante backoffice gegevensverzamelingen is gerealiseerd, inclusief synchronisatie.

Opleiding en documentatie Naast het voldoen aan de voorwaarden die aan de inrichting worden gesteld dient de Inschrijver er zorg voor te dragen dat de belanghebbenden bij de gemeenten (FO/KCCmedewerkers, functioneel beheerders, technische beheerders, ontwikkelaars en dergelijke) adequaat zijn getraind en van documentatie voorzien, zodat zij volledig zelfstandig de hele Midoffice Suite (inclusief eventuele integratiemodulen) kunnen gebruiken en functioneel en technisch beheren, onderhouden en uitbouwen.


76


5.7.2 Eisen implementatie E23

Continuïteit maatwerk Eventueel maatwerk moet blijvend worden ondersteund in volgende releases van de geoffreerde applicatie(s).

E24

Opleiding Inschrijver dient de (eind)gebruikers zoals FO/KCC-medewerkers, functioneel- en technisch beheerders en andere belanghebbenden van de gemeente zodanig te trainen en van documentatie te voorzien dat de gemeenten zelfstandig het complete fronten midoffice (inclusief eventuele integratiemodulen) kunnen gebruiken, functioneel en technisch kunnen beheren en kunnen onderhouden.

E25

Documentatie Alle eindgebruikersdocumentatie dient volledig in het Nederlands te zijn gesteld.

E26

Taal Sleutelfiguren binnen het project zoals de projectmanager, projectleider(s), ontwerper, technisch architecten en docenten dienen Nederlands te spreken.

E27

Implementatieteam Teamleden van de Inschrijver die bij de uiteindelijke implementatie(s) betrokken zijn, dienen ook bij een eventuele PoC betrokken te zijn, in een gelijkwaardige rol.

E28

Planning Inschrijver dient bij elk van de gemeenten die de onderhavige opdracht aan hem gunnen de Initiële implementatie binnen zes maanden te hebben afgerond, gerekend vanaf het moment dat de betreffende gemeente de opdracht tot Initiële implementatie geeft.

5.7.3 Vragen implementatie V80

* Plan van Aanpak Geef een Plan van Aanpak om de Initiële implementatie van de Midoffice Suite voor een gemeente te realiseren zoals geschetst , inclusief training en ondersteuning. Beschrijf, als onderdeel van dit Plan van Aanpak, een zo specifiek mogelijke planning voor de onderhavige opdracht, inclusief een specificatie van wat er wanneer van wie verwacht wordt. Denk hierbij onder meer aan deliverables, verantwoordelijkheden, randvoorwaarden, kritieke succesfactoren en dergelijke, zowel van uw kant als van de kant van de gemeenten. Specificeer in ieder geval de te verwachten personele inzet van zowel uw kant als van de kant van de gemeente. Geef ook aan of, en zo ja hoe, u hulp kunt bieden aan de gemeente voor wat betreft de organisatorische aspecten van de implementatie.


77


Geef zowel in het algemeen als per product (zie ook bijlage 8.12) aan welke problemen u verwacht bij de Initiële implementatie. Denk hierbij onder meer aan koppelingen met backoffice applicaties en gegevensverzamelingen (synchronisatie-, transactie- en statuskoppelingen), de vulling en synchronisatie van het gegevensmagazijn, prefill en validaties (vanuit / tegen het gegevensmagazijn) bij webintake, de inrichting van en statusupdates naar het zakenmagazijn en dergelijke. Maak bij de beantwoording van deze vraag onderscheid tussen de implementatie van de eerste zeven producten en vervolgimplementaties, alsmede tussen de mogelijkheid waarbij gebruik wordt gemaakt van ASP en de mogelijkheid waarbij installatie lokaal geschiedt (indien van toepassing) en beschrijf ten slotte de respectievelijke voor- en nadelen van beide mogelijkheden. V81

Migratie Beschrijf hoe u omgaat met migratie c.q. conversie van reeds aanwezige systemen en gestructureerd (velden / records) en semi-gestructureerd (documenten) gegevens. Geef ook aan hoe u de migratie van eventueel reeds aanwezige vormen van elektronische dienstverlening (gemeentelijke producten) naar de geoffreerde oplossing denkt aan te pakken. Geef bij de beantwoording van deze vraag zomogelijk een zo gedetailleerd mogelijke planning, inclusief relevante ‘milestones’.

V82

Parallelle implementaties Beschrijf hoe u om denkt te gaan met eventuele parallelle implementaties bij meerdere gemeenten. Onderscheid hierbij een aantal scenario’s waarbij de onderhavige opdracht aan u gegund wordt door respectievelijk één, twee, drie, vier en alle vijf gemeente(n), waarbij de Initiële implementaties bij twee of meer gemeenten deels parallel worden uitgevoerd. Specificeer bij elk scenario de te verwachten personele inzet van zowel uw kant als van de kant van de gemeente.

V83

* Team Geef aan welk team u wilt inzetten voor een eventuele Proof of Concept en de Initiële implementatie van de Midoffice Suite en geef CV’s van die teamleden waaruit de benodigde ervaring blijkt voor het realiseren van deze opdracht. Geef hierbij voor elk van de geoffreerde teamleden aan of deze betrokken zijn geweest bij soortgelijke implementaties, bij voorkeur van dezelfde applicatie(s), en zo ja in welke rol. Onderscheid ook bij de beantwoording van deze vraag een aantal scenario’s waarbij de onderhavige opdracht aan u gegund wordt door respectievelijk één, twee, drie, vier en alle vijf gemeente(n), waarbij de Initiële implementaties bij twee of meer gemeenten deels parallel worden uitgevoerd.

V84

* Gemeentelijke producten Geef een lijst van gemeentelijke producten, zoals een binnengemeentelijke verhuizing, welke u reeds bij andere gemeenten hebt geïmplementeerd. Geef bij elk daarvan aan of daarbij gebruik wordt gemaakt van een gegevensmagazijn, zakenmagazijn, document management en/of workflow management, alsmede of daarbij backoffice koppelingen zijn gerealiseerd (inclusief een korte toelichting per koppeling). Beschrijf hierbij ook eventuele ‘interne’ dienstverlening die met behulp van de geoffreerde applicatie(s) is


78


gerealiseerd (denk aan het reserveren van beamers, vergaderzalen, het aanmelden van bezoekers en dergelijke), inclusief eventuele koppelingen met de desbetreffende systemen. Geef aan of, en zo ja hoe en in hoeverre, de betreffende gemeentelijke producten (inclusief ‘interne’ dienstverlening) op eenvoudige wijze bij de gemeenten van het Consortium geïmplementeerd kunnen worden. V85

Aangeboden applicaties Geef een opsomming van de applicatienamen en versies van de bij de beantwoording van deze vragen genoemde applicaties, alsmede de additionele modules en versies. Geef hierbij aan welke applicaties en additionele modules open source zijn en of Escrow van sources en dergelijke mogelijk is. Als er afhankelijkheden zijn tussen geoffreerde applicaties, geef dit aan (bijvoorbeeld wanneer fronten midoffice componenten technisch of functioneel niet gescheiden kunnen worden). Geef tevens een opsomming van alle (beschikbare) aan de opgegeven applicaties gerelateerde applicaties die volgens u mogelijk relevant zijn voor het Consortium en niet bij de Offerte begrepen zijn op basis van uw beantwoording van het Programma van Eisen.

V86

* Kostenstructuur Beschrijf de kostenstructuur van de geoffreerde applicatie(s) en eventuele extra modules. Maak hierbij onderscheid tussen de fronten midoffice onderdelen. Geef aan welke kosten eenmalig zijn, en wat de jaarlijkse onderhoudskosten zijn. Beschrijf hoe de licentiestructuur is opgebouwd (bijvoorbeeld afhankelijk van het aantal CPU’s, het soort omgeving (OTAP), het aantal klanten en ambtenaren en dergelijke). Geef de kostenopbouw van levering en onderhoud van de aangeboden applicatie, uitgaande van een licentie voor lokale hosting per gemeente of als ASP. Vermeld daarbij tevens de kosten van noodzakelijke en optionele, al dan niet thirdparty, add-on modules en eventueel maatwerk, indien deze zijn genoemd bij de beantwoording van het Programma van Eisen. Het kostenschema moet gedimensioneerd zijn voor het huidige en toekomstige interne en externe gebruik. Geef hierbij aan hoe omgegaan wordt met opties en extra’s (minder- en meerprijzen, zie ook hoofdstuk 6) en hoe kortingen worden berekend voor de scenario’s waarbij de onderhavige opdracht aan u gegund wordt door respectievelijk één, twee, drie, vier en vijf gemeenten, alsmede door eventuele additionele gemeenten. NB: de beoordeling vindt plaats op transparantie. Hier is echter wel de voorkeur voor het onderscheiden van de mogelijkheden ASP en lokale installatie. De prijs wordt gevraagd in hoofdstuk 6.

V87

Implementatiekosten Beschrijf de geschatte kosten en doorlooptijd van de volledige implementatie van de aangeboden applicatie(s) voor de top-34 van gemeentelijke producten (de norm van 67% elektronische dienstverlening in het kader van het Programma Andere Overheid), inclusief de kosten voor training, support, onderhoud en dergelijke. Geef aan wat de gemiddelde, minimale en maximale kosten zijn en geef enkele praktijkvoorbeelden.


79


Het Consortium schat de kosten voor de volledige implementatie op drie maal de kosten voor de Initiële implementatie. Geef aan of dit reëel is en waarom wel / niet. Geef aan in hoeverre het mogelijk is dat gemeenten na de Initiële implementatie deze top-34 van gemeentelijke producten zoveel mogelijk zelf ‘inregelen’ in de geoffreerde applicatie(s), aan welke voorwaarden dat verbonden is (inclusief opleiding van medewerkers en eventuele ondersteuning door externe partijen, onder vermelding van een indicatie van d kosten daarvan) en welke inspanning dit vergt voor de gemeente (inclusief een schatting van de kosten en het aantal benodigd FTE’s, zowel per jaar als in totaal). NB: de beoordeling vindt plaats op transparantie. Hier is echter wel de voorkeur voor het onderscheiden van de mogelijkheden ASP en lokale installatie. De prijs wordt gevraagd in hoofdstuk 6. V88

* Roadmap en visie Beschrijf uw visie op gemeentelijke elektronische dienstverlening en hoe dit zich verhoudt tot het geschetste fronten midoffice / klantcontactcentrum concept, nu en in de toekomst (zowel voor kortere als langer termijn). Ga hierbij expliciet in op de mate van ‘toekomstvastheid’ van de geoffreerde applicatie(s) met betrekking tot huidige en toekomstige ontwikkelingen zoals basisregistraties, Burger Service Nummer (BSN), Digitaal Klant Dossier (DKD), ontwikkelingen rondom de omgevingsvergunning, de WMO en dergelijke, alsmede op ontwikkelingen rondom relevante (open) standaarden (zoals STUF). Beschrijf uw visie op de toekomstige ontwikkeling van de geoffreerde applicaties, mede in het kader van de voornoemde visie op elektronische dienstverlening en het fronten midoffice / klantcontactcentrum concept (bijvoorbeeld: wat is de situatie bij gemeenten over drie jaar en hoe passen geoffreerde applicaties daarin). Ga bovendien in op functionele en technologische aspecten, eventuele uitfasering / vervanging van (onderdelen van) per applicatie, releaseplanning, focus op gemeenten en overige overheden, integratie tussen de verschillende geleverde applicaties, etc. Doe dit voor zover relevant per applicatie. Indien verschillende geoffreerde applicaties worden geleverd door verschillende partijen, geef aan of en hoe u in de toekomst verwacht de interoperabiliteit tussen de applicaties te kunnen garanderen. Geef van de geoffreerde applicatie(s) aan wat de bekende te verwachte datum en versie van nieuwe releases zijn. Geef per applicatie tevens aan wat de release politiek is (het aantal grote releases, aantal kleine releases, patches en dergelijke) van de applicatieleverancier. Geef aan in welke mate de aangeboden applicatie(s) en de bijbehorende ontwikkelaar / leverancier toekomstvast is in termen van producten bedrijfstrategie en de daarbij behorende ontwikkelinspanning voor de komende jaren. Indien open source, geef aan of, hoe en welke commerciële partijen betrokken zijn bij nieuwe releases. Geef aan wat het beleid is rondom het voor alle typen gebruikers- en ontwikkelaars aanbieden van documentatie van nieuwe versies.

V89

Training Geef aan welke mogelijkheden u voor de geoffreerde applicatie(s) beschikbaar heeft voor opleiding, training en support per rol. Denk hierbij onder meer aan de volgende


80


rollen: technisch en functioneel beheerders, ontwikkelaars, FO/KCC-medewerkers en dergelijke. Vermeld onder meer de duur en inrichting van opleidingstrajecten, training per gemeente naar aantal dagen, aantal personen per rol, prijzen en dergelijke. Geef hierbij onder meer aan of opleidingen bij gemeenten op locatie kunnen plaatsvinden, of opleidingen eventueel gecombineerd kunnen worden over meerdere deelnemende gemeenten en welke mogelijkheden u biedt op het gebied van het ‘train de trainer’ en soortgelijke opleidingsmethoden. Maak bij de beantwoording van deze vraag onderscheid tussen training zodat men de geoffreerde applicatie(s) zelfstandig kan gebruiken, onderhouden en (functioneel en technisch) kan beheren enerzijds en training voor het door de gemeente zelf kunnen ontwikkelen van additionele functionaliteit anderzijds. Dit betreft in het bijzonder het gebruikersvriendelijk, zonder dat kennis van programmeertalen en dergelijke nodig is, kunnen realiseren van nieuwe gemeentelijke producten (zoals vergunningaanvragen en dergelijke) middels de geoffreerde applicatie(s). V90

Onderhoud en ondersteuning Geef aan of er gebruikersgroepen (formeel of informeel, bijvoorbeeld via forum of website) bestaan voor de geoffreerde applicatie(s) en beschrijf deze. Maak hierbij een onderscheid tussen zowel eindgebruikers als ontwikkelaars. Geef een overzicht van de beschikbare documentatie per rol. Beschrijf de soorten onderhoud die u ten aanzien van de geoffreerde applicatie(s) kunt bieden. Denk hierbij onder meer aan preventief / correctief onderhoud, onderhoud op standaardproducten / maatwerk, servicelevels, responsetijden, ondersteuning on-site / of-site, (telefonische) helpdesk en bereikbaarheid daarvan, functionele / technische ondersteuning, on-line ondersteuning en dergelijke. Beschrijf hierbij ook of, en zo ja in hoeverre en hoe, u de geoffreerde applicatie(s) aanpast aan veranderingen op het gebied van regelgeving, standaarden en dergelijke Indien open source, geef aan of, hoe en welke commerciële partijen betrokken zijn bij onderhoud en support.


81


6

FINANCIËN

Dit hoofdstuk bevat vragen over de prijs en een aantal financiële eisen waaraan de Inschrijver bij het uitbrengen van de Offerte moet voldoen. V91

Software Geef conform tabel 5 de kosten voor alle applicaties die noodzakelijk zijn om de in het Programma van Eisen beschreven functionaliteiten te realiseren. Hierbij horen ook de eventueel noodzakelijke add-on modules (onder vermelding van hun versienummers) en eventueel maatwerk. Wanneer bij de beantwoording van het Programma van Eisen sprake is van add-ons en/of maatwerk bovenop de standaardapplicatie(s), wordt ervan uitgegaan dat de kosten hiervan ook gespecificeerd zijn in tabel 5. Het aantal licenties is inclusief licenties voor de ontwikkel-, test-, acceptatie- en productieservers, uitgaande van een middelgrote gemeente (50.000 tot 100.000 inwoners). De kosten dienen te worden gedimensioneerd voor het huidige en toekomstige interne en externe gebruik. NB: het Consortium heeft de voorkeur voor server-based licenties. Software licenties (eenmalig)

Onderhoud en ondersteuning (jaarlijks)

Aantal licenties

Applicatie 1 Applicatie 2 Applicatie … Add-on 1 Add-on 2 Add-on … Maatwerk 1 Maatwerk 2 Maatwerk … Tabel 5: prijsopgave software (in Euro’s, inclusief BTW) V92

Initiële implementatie Geef per gemeente de kosten voor de Initiële implementatie. De kosten voor iedere Initiële implementatieopdracht dient u conform tabel 6 per deelproject (installatie, basisimplementatie, inrichten top-7 producten, opleiding, overige kosten en migratie) en per onderdeel van de Midoffice Suite (Frontoffice, KCC en Broker) te specificeren. Geef tenslotte fixed price de totale kosten voor de Initiële implementatie.

Onderdeel Installatie Basisimplementatie Inrichten top-7 producten Opleiding (eenmalig) Overige kosten (specificeer) Migratie Totale kosten (fixed price)

Frontoffice

KCC

Broker + adapters

Tabel 6: prijsopgave Initiële implementatie (in Euro’s, inclusief BTW) Commercieel vertrouwelijk

82


V93

Fixed price Geef, in aansluiting op de vragen V91 en V92, per gemeente de fixed price op basis van de licentiekosten (exclusief kosten voor licenties van operating systemen en databases), de kosten voor onderhoud en ondersteuning van de software over vijf jaar en de kosten voor de fixed price geoffreerde Initiële implementatie (inclusief onderhoud, ondersteuning en opleiding).

V94

Korting Om eventuele prijsvoordelen ten aanzien van het aantal gemeenten in kaart te brengen, verzoeken wij u voor elk van de scenario’s waarbij één, twee, drie, vier of alle vijf van de gemeenten in het Consortium de onderhavige opdracht aan u gunnen de fixed price te geven conform vraag V93. Geef bovendien aan welke mogelijkheden u biedt voor andere gemeenten (die nu niet tot het Consortium behoren) om later, bij aansluiting bij het Consortium, van hetzelfde aanbod gebruik te maken. Beschrijf in dat kader bij welke totale inwonertallen u welke kortingen biedt op licentiekosten (uitgezonderd open source software). Beschrijf ten slotte eventuele ‘kickback’-regelingen, waarbij de gemeenten in het Consortium een terugverdieneffect genieten wanneer andere gemeenten aansluiten of u het voor het Consortium ontwikkelde maatwerk en/of producten, processen en dergelijke vermarkt.

V95

Tarieven Geef conform tabel 7 per functieprofiel aan welke tarieven u hanteert voor de door u geoffreerde teamleden tijdens de Initiële implementatie. Geef bovendien conform tabel 8 aan wat hun overwerk- en weekendtarieven zijn. Geef ten slotte de beschikbaarheid van het team aan, alsmede de bijbehorende tarieven, bij een eventuele vervolgopdracht na de Initiële implementatie. Profiel

Uurtarief (Euro’s)

Projectmanager Projectleider Service engineer Netwerkspecialist System specialist ... Tabel 7: uurtarieven (in Euro’s, inclusief BTW) Tijden Werkdagen van 18:00 tot 20:00 uur Werkdagen van 20:00 tot 07:30 uur Zaterdagen, zondagen en christelijke feestdagen

Tariefopslag (percentage)

Tabel 8: overwerk- en weekendtarieven (in opslagpercentages)


83


V96

Minderwerk De gemeenten die deelnemen in het Consortium behouden zich het recht voor om te besluiten bepaalde onderdelen en/of componenten van de Midoffice Suite niet of niet direct af te nemen. In dat laatste geval heeft een gemeente het recht om de niet afgenomen onderdelen en/of componenten gedurende de contractperiode alsnog tegen de geoffreerde prijzen af te nemen (de zogeheten ‘optie’-regeling). Hiervan kunnen gemeenten bijvoorbeeld gebruikmaken wanneer zij één of meerdere reeds aanwezige 3P applicaties willen (blijven) gebruiken. Die componenten worden hier ‘optionele componenten’ genoemd. De onderstaande tabel 9 geeft een overzicht van deze optionele componenten. Inschrijver wordt verzocht om per optionele component, voor zover deze niet onlosmakelijk is verbonden met de geoffreerde applicatie(s), de minderprijs op te geven. De minderprijs is het bedrag dat een afnemer minder hoeft te betalen bij het niet afnemen van de betreffende optionele component ten opzichte van de volledige Midoffice Suite en betreft zowel de software als de bijbehorende implementatiediensten.

Optionele componenten Frontoffice Zoeken Vraaggeleiding Product/dienstencatalogus Beperkt document management Beperkt workflow management Beperkt relatiebeheer Geo-informatie …

Minderprijs

Tabel 9: minderwerk (in Euro’s, inclusief BTW) V97

Meerwerk Ten behoeve van het gebruik van bepaalde reeds aanwezige 3P applicaties dient een integratie/koppeling te worden gerealiseerd tussen de aangeboden Midoffice Suite en de betreffende applicaties. De onderstaande tabel 10 geeft een overzicht van de 3P applicaties die op dit moment reeds bij één of meerdere gemeenten in gebruik zijn en waarmee een integratie/koppeling gerealiseerd dient te worden. Inschrijver wordt gevraagd om per gemeente en per applicatie (indien van toepassing) de meerprijs van de betreffende integratie/koppeling op te geven. De meerprijs is het bedrag dat een afnemer meer dient te betalen ten opzichte van de volledige Midoffice Suite en betreft zowel de software (bijvoorbeeld extra adapters) als de implementatiediensten.


84


Integratie/koppeling Frontoffice Product/dienstencatalogus Document management Relatiebeheer Geo-informatie Datadistributie Content management …

Applicaties Zie bijlage 8.10 Zie bijlage 8.10 Zie bijlage 8.10 Zie bijlage 8.10 Zie bijlage 8.10 Zie bijlage 8.10 Zie bijlage 8.10

Meerprijs

Tabel 10: meerwerk (in Euro’s, inclusief BTW) V98

Extra’s Naast het meer- en minderwerk zoals hierboven besproken, zijn er ook gemeenten die van Inschrijver bepaalde functionaliteiten vragen die niet direct onderdeel uitmaken van de Midoffice Suite. Die functionaliteiten worden hier ‘extra functionaliteiten’ of extra’s genoemd. Voorbeelden van dergelijke extra’s zijn de implementatie van één of meer additionele producten en het realiseren van een additionele integratie/koppeling tussen de Midoffice Suite en een 3P applicatie. De extra’s worden beschreven in de gemeentespecifieke bijlagen (bijlagen 8.3 t/m 8.7). In tegenstelling tot het hiervoor reeds gevraagde meer- en minderwerk is Inschrijver niet verplicht om deze extra’s te offreren. Specificeer per beschreven extra de meer-/minderprijs ten opzichte van de volledige Midoffice Suite (dit betreft zowel de software als de implementatiediensten).

E29

De geoffreerde frontoffice applicatie(s), dat wil zeggen die applicatie(s) waar de klant mee in aanraking komt, mogen niet op basis van named users worden aangeboden, ook niet voor wat betreft de eigen medewerkers van een gemeente.

E30

Alle geldbedragen in de Offerte zijn vastgesteld in Euro’s. Veranderingen in ruilverhouding tussen de Euro en andere valuta hebben geen effect op het tarief.

E31

Alle geldbedragen in de Offerte zijn inclusief omzetbelasting (BTW), met uitzondering van het antwoord op de eisen E13 en E14.

E32

Alle geoffreerde prijzen dienen te zijn gebaseerd op de in het Bestek genoemde specificaties.

E33

De in de Offerte genoemde tarieven voor diensten dienen vast en onveranderlijk te zijn tot 1 mei 2007, daarna mogen ze tijdens de duur (en eventuele verlenging) van de overeenkomst slechts gewijzigd worden met het CBS-indexcijfer voor overige dienstverlening.

E34

In uitzondering op eis E33 is de Inschrijver gedurende de looptijd van de te sluiten overeenkomst verplicht om (componenten van) tarieven te verlagen indien zich in de relevante markt kostenverlagingen voordoen (marktconformiteit).

V99

Geef aan hoe u eis E34 gaat invullen. Mogelijkheden hiervoor kunnen zijn een vaste korting op uw standaard bruto-prijslijst of het gebruik van zogeheten ‘not to exceed’


85


prijzen. Omschrijf uw voorstel en de mogelijkheden voor het Consortium om de prijsstelling te controleren. E35

U dient een betalingstermijn van 30 dagen (na factuurdatum) te hanteren, met dien verstande dat facturering plaatsvindt na acceptatie door de klant.


86


7

JURIDISCHE VOORWAARDEN

Bij dit Bestek is een conceptovereenkomst gevoegd (bijlage 8.18). In dit hoofdstuk worden de eisen en vragen met betrekking tot deze conceptovereenkomst gesteld. V100 Inschrijver wordt verzocht de conformiteitenlijst in bijlage 8.19 in te vullen. Deze biedt de mogelijkheid om per artikel aan te geven of het tekstvoorstel akkoord is. Daar waar de Inschrijver wenst af te wijken van de voorgelegde bepaling(en) geeft hij dit aan d.m.v. het invullen van een ‘V’ in de kolom ‘Niet Akkoord’. In dat geval dient Inschrijver op het formulier een tekstvoorstel te doen. Als Inschrijver ‘Niet akkoord’ is en geen nieuw tekstvoorstel doet dan wordt er van uitgegaan dat Inschrijver niet instemt met het artikel. Indien de Inschrijver van mening is dat in de voorgelegde overeenkomst zaken ontbreken, kan dit onderaan het formulier aangeven worden met een tekstvoorstel. Geef daarbij aan na welk artikelnummer het voorstel moet worden opgenomen. NB: het Consortium is geenszins verplicht de voorgestelde tekstvoorstellen over te nemen. E36

Voor de Proof of Concept gelden de algemene voorwaarden in bijlage 8.14. Inschrijver dient zich akkoord te verklaren met de gestelde voorwaarden.

E37

De conceptovereenkomst kan alvorens deze door partijen wordt ondertekend door het Consortium worden gewijzigd (in de ruimste zin des woords) en nader worden uitgewerkt. De Inschrijver stemt bij voorbaat in met wijzigingen en nadere uitwerkingen die voor hem niet aantoonbaar zwaarder uitvallen dan in de conceptovereenkomst is omschreven, en met wijzigingen en nadere uitwerkingen die overeenkomen met de eisen en vragen zoals beantwoord in de Offerte. Slechts wijzigingen en nadere uitwerkingen die voor de Inschrijver wel aantoonbaar zwaarder uitvallen dan in de conceptovereenkomst, zijn vatbaar voor nadere afspraken.

E38

De Inschrijver zal in de Offerte geen algemene voorwaarden opnemen of hiernaar verwijzen.

E39

Op deze aanbesteding en de eventueel te sluiten overeenkomsten is het Nederlands recht van toepassing.

E40

De overeenkomst wordt aangegaan voor een periode van drie jaar, met tweemaal de mogelijkheid van verlenging met een periode van één jaar.

Dit Bestek en de Offerte van de gegunde Inschrijver maken deel uit van de af te sluiten overeenkomst.


87


8

BIJLAGEN

8.1

EGEM Midoffice Referentiearchitectuur V0.9

Apart bijgevoegd Zie apart bijgevoegd document EGEM Referentiemodel Midoffice V0.9.pdf. Hoewel het hier nog om een conceptversie van het betreffende Referentiemodel gaat (het bijgevoegde document is versienummer 0.9, d.d. 24 mei 2006), is het inmiddels voldoende gevorderd om als toelichting bij het onderhavige Bestek te kunnen fungeren. Het onderhavige Bestek is dan ook gedeeltelijk gebaseerd op dit EGEM Referentiemodel Midoffice, hoewel dit Bestek een enigszins afwijkende terminologie hanteert. In dergelijke gevallen is het Bestek leidend. Het bijgevoegde document dient, in afwachting van publicatie van de definitieve versie, als vertrouwelijk te worden aangemerkt. Zie voor meer informatie de volgende website: www.egem.nl/projecten/voorhoedegemeenten/raadscommissies/midoffice.


88


8.2

Nederlandse Overheid Referentie Architectuur (NORA) V0.8

Online beschikbaar Net als het EGEM Referentiemodel Midoffice is ook de Nederlandse Overheid Referentie Architectuur (NORA) nog in ontwikkeling (ten tijde van de publicatie van dit Bestek is de meest recente versie van de NORA versienummer 0.8, d.d. 31 maart 2006). In tegenstelling tot het EGEM Referentiemodel Midoffice is de NORA echter wel openbaar en derhalve niet vertrouwelijk. Versie 0.8 van het betreffende document is dan ook te vinden op de volgende website: http://www.e-overheid.nl/data/files/architectuur/nora-versie-08g.pdf. Versie 0.8 van de NORA is desgewenst ook opvraagbaar via het in paragraaf 2.1 genoemde E-mail adres.


89


8.3

Gemeente Alphen aan den Rijn

De gemeentespecifieke bijlage van de gemeente Alphen aan den Rijn bestaat uit een drietal onderdelen. Het eerste onderdeel (paragraaf 8.3.1) bevat relevante achtergrondinformatie over de gemeente Alphen aan den Rijn, waaronder een beknopte schets van de gemeente en de visie en ambities ten aanzien van (elektronische) dienstverlening, alsmede een beschrijving van de huidige situatie en de actuele ontwikkelingen. Het tweede onderdeel (paragraaf 8.3.2) bevat een beschrijving van het eventuele meer- en minderwerk zoals besproken in hoofdstuk 6. Het derde onderdeel ten slotte (paragraaf 8.3.3) bevat een beschrijving van de extra’s zoals besproken in hoofdstuk 6. 8.3.1 Algemene informatie Introductie De gemeente Alphen aan den Rijn (www.alphenaandenrijn.nl) ligt in het groene hart van de Randstad en telt meer dan 70.000 inwoners. De kwaliteit van wonen, werk en leefomgeving staan centraal in deze gemeente. Alphen aan den Rijn is een stad met mensen van verschillende afkomst en achtergrond. Om te weten wat er leeft binnen de gemeentegrenzen, staat de gemeente Alphen aan den Rijn tussen de mensen en niet er boven. Zij werkt aan een cultuur die dynamisch, ondernemend, betrouwbaar en open is. Denken en handelen vanuit de belangen van de burger is hierbij het uitgangspunt. De gemeenteraad is het hoogste orgaan binnen de gemeentelijke organisatie. De griffie ondersteunt de raadsleden. Het college van B&W staat onder de raad. Gemeenteraad en college vormen samen het gemeentebestuur. De gemeentelijke organisatie is verdeeld in drie directies, te weten: Bewoners, Grondgebied en Beleid, Middelen en Facilitaire diensten (BMF). Iedere directie bestaat weer uit een aantal afdelingen. Bij de gemeente werken in totaal 609 medewerkers, waarvan 50 medewerkers in de buitendienst. Het organigram van de gemeente Alphen aan den Rijn is afgebeeld in figuur 4. Visie en ambitie (elektronische) dienstverlening • Dienstverleningsconcept Op 9 november 2004 heeft het College van B&W de I-visie met de titel ‘Dienstverlening naar de burger, dienstverlening bij de burger’ vastgesteld. Het einddoel van dit programma is het verhogen van de kwaliteit van dienstverlening voor de burgers. In 2007 moet er een score zijn van 7 of beter gegeven door 80% van de burgers in de stadspeiling. De idee is dat ICT een belangrijke bijdrage kan leveren aan de verbetering van de dienstverlening. Voorop staat een vergaande vereenvoudiging van aanvraag- en werkprocessen. Deze ambitie is nu ook opgenomen in het programma dienstverlening van het collegeprogramma 2006 - 2010. • Programma dienstverlening (collegeprogramma) “Wij hechten veel waarde aan een vraaggerichte dienstverlening, zowel voor bewoners als voor ondernemers. Hierbij zoeken we zo veel mogelijk aansluiting bij maatregelen van de rijksoverheid, zoals het project ‘Andere Overheid’.


90


Figuur 4: organigram gemeente Alphen aan den Rijn De komende periode gaan we planmatig kijken naar de regels waarmee burgers en bedrijven te maken krijgen. Daarbij worden dubbelingen, onderlinge tegenstrijdigheden en nodeloos ingewikkelde regels afgeschaft of vervangen door eenvoudige regels. De doelgroepen die hier relatief veel last van hebben zullen wij bij dit proces betrekken. Minder regels betekent ook dat de gemeente op sommige terreinen een stapje terug doet. Burgers, instellingen en bedrijven krijgen zo meer ruimte om zaken zelf in te vullen. Wij willen de doorlooptijden terugdringen. Daarom worden in de dienstverlening aan de burger de procedures zoveel mogelijk gestroomlijnd. Door sommige processen gelijktijdig te laten lopen. Door alleen strikt nodige informatie te vragen en zeker geen informatie opnieuw te vragen die een burger al eerder aan de gemeente heeft verstrekt. Door het verder gebruiken van elektronische dienstverlening en het verder invullen van de éénloketgedachte. En vooral door steeds de efficiency van de gemeentelijke procedures kritisch te bekijken en te verbeteren. De klanttevredenheid over de dienstverlening is voor ons een belangrijk criterium. De kernen Aarlanderveen en Zwammerdam blijven beschikken over een passende gemeentelijke dienstverlening.


91


Over onze dienstverlening hebben we binnen onze organisatie heldere afspraken gemaakt. We noemen dat onze servicenormen. Het zijn afspraken over de snelheid waarmee we producten leveren, over de maximale wachttijden bij de balies en over onze bereikbaarheid van de medewerkers. Zo weten onze klanten wat zij van ons kunnen verwachten. Als wij ons aan onze afspraken houden, zullen zij tevreden zijn. Ons ideaalbeeld is dat de klant bij het benaderen van de gemeente, via wat voor kanaal dan ook, snel en kwalitatief goed bediend wordt.” • Elektronische dienstverlening De ondersteuning die ICT levert aan het dienstverleningsconcept betreft een generieke informatievoorziening die de drager vormt voor elektronische dienstverlening. Daarbij wordt onderscheid gemaakt tussen een voorziening voor het frontoffice en een voorziening voor het midoffice. Huidige situatie • Klanten Klanten van de gemeente Alphen aan den Rijn stellen dezelfde eisen aan hun gemeente als aan elke andere organisatie waarbij ze klant zijn. Men verwacht dat een kwaliteitsproduct of -dienst tegen een zo laag mogelijk tarief, zo snel mogelijk wordt geleverd. Een klant heeft een aantal manieren (kanalen) om bij de gemeente ‘binnen te komen’: via de balie, telefoon, post, e-mail en website. Nu zijn deze kanalen vaak nog per afdeling verdeeld. Uitzonderingen hierop vormen het centrale 0900-telefoonnummer en het centrale e-mail adres. Bij binnenkomst via een van deze kanalen kan de klant tegen onvoorziene en ongewenste zaken aanlopen. • Balie Bij baliebezoek kan het bijvoorbeeld voorkomen dat men met verschillende vragen komt, en er vervolgens achter komt dat de beantwoording daarvan alleen bij verschillende loketten kan plaatsvinden; de plekken dus waar de specialisten hun werk verrichten. Gevolg daarvan is dat het de klant veel tijd en energie kost om tevreden huiswaarts te keren. • Telefoon Bij een telefonisch contact moet er soms veel worden doorverbonden, met name omdat de betreffende medewerker niet de kennis voorhanden heeft om vragen direct te beantwoorden. Het gebeurt ook dat er wordt doorverbonden naar collega’s die niets met het onderwerp van doen hebben, of gezochte medewerkers zijn niet aanwezig waardoor klanten opnieuw contact op moeten nemen. • E-mail Een E-mail bericht heeft ook niet altijd het gewenste effect. Momenteel wordt inkomende E-mail niet geregistreerd maar doorgezet naar de verschillende afdelingen. Komt E-mail wel aan en wordt deze serieus door medewerkers c.q. afdelingen behandeld? Kunnen we de inhoud toetsen en daarna een keuze maken tussen direct beantwoorden, doorsturen naar de betreffende afdeling of doorsturen voor officiële registratie? Er is onlangs wel een pilot gestart met E-mail tracking.


92


• Website Het web gebruiken we op dit moment nog voornamelijk voor het bieden van informatie. Een uitzondering hierop is het aanbieden van interactieve informatie over de WOZ-taxatie. Ook is de mogelijkheid beschikbaar tot personalisatie van nieuws en informatie. Klanten worden op de hoogte gehouden via de elektronische nieuwsbrief. In de webmonitor van overheid.advies.nl staan we op plek 55. Dat komt voornamelijk doordat we nog geen Edienstverlening, DigiD en E-betalen aanbieden. De huidige website is ontwikkeld in 2000. Voor het najaar 2006 willen we de website vernieuwen en in het najaar voorzien van Ediensten. • Post Op het postkanaal heeft de gemeente Alphen aan den Rijn van oudsher wat meer controle. Ook hier is het echter mogelijk dat de post niet aankomt bij de juiste personen, of dat er geen overzicht is of een aanvraag binnen de juiste termijn wordt behandeld. Een klant heeft tijdens de behandeling van een aanvraag momenteel geen inzicht in de voortgang daarvan. Voor de postregistratie en afhandeling maken we nu nog gebruik van Docman (Circle). In 2007 willen we dat gaan vervangen. • Medewerkers Medewerkers van de gemeente Alphen aan den Rijn doen hun best om klanten zo goed mogelijk van dienst te zijn. Zij zijn zich ervan bewust dat de klant snelheid en kwaliteit van hen verwacht. Toch ondervinden zij soms, net als de klant, hinder van de manier waarop zaken georganiseerd zijn. Het is vervelend om te moeten zeggen “dat weet ik niet, daarvoor moet u bij mijn collega zijn van een ander loket”. Het zou prettig zijn om te kunnen beschikken over een naslagwerk waarin de meest voorkomende vragen te vinden zijn. Het is ook frustrerend om de klant, voor de zoveelste keer, zijn naam en adresgegevens te moeten vragen. Zeker als een klant tegen je zegt: “ik heb net vorige week uw collega gesproken”. Als die collega toevallig niet aanwezig is, is het niet mogelijk om te achterhalen wat er die vorige keer besproken is. Datzelfde speelt ook als het gaat om e-mail of post. Medewerkers hebben maar beperkte middelen om te achterhalen wat er eerder is afgesproken. Veel informatie, zoals bijvoorbeeld adresgegevens, moeten opnieuw worden ingevoegd in een eigen werksysteem. Dat kost onnodig veel tijd. Vaak is het zo dat een klant een vraag heeft die (achtereenvolgens) door diverse afdelingen moet worden behandeld. Op dit moment is het lastig om te bekijken waar de vraag ‘uithangt’ in de keten van activiteiten en hoe het ermee staat. Medewerkers moeten daardoor tijd investeren in het natrekken van zaken. • Managers en bestuurders Voor managers en bestuurders is het moeilijk om te zien of het goed gaat. Van onze klanten krijgen we informatie via klantenmonitor en stadspeiling. We weten dan wat klanten verbeterd willen zien. Iedere manager levert maar een klein stukje van de dienst en doet dat zo goed mogelijk, maar er is niemand die overzicht houdt totdat de vraag van de klant is beantwoord. In de praktijk blijkt dat overdrachtsmomenten tussen verschillende onderdelen van de keten gevaarlijke momenten zijn.


93


Helaas maakt iedereen wel eens mee dat iets niet duidelijk is overgedragen, er iets zoekraakt in de interne post of blijft liggen bij een zieke collega. Managers kunnen alleen nog niet nagaan waar in de keten behoefte is aan extra ondersteuning of andere hulpmiddelen. Ze kunnen daar het bestuur niet gericht om vragen. Bestuurders hebben zo minder gelegenheid om accenten te leggen op de dienstverlening. Actuele ontwikkelingen Om de elektronische dienstverlening vorm te geven is een overkoepelende organisatie Edienstverlening opgezet met daarin verschillende activiteiten die hun impact hebben op het verbeteren van de (elektronische) publieke dienstverlening. Opdrachtgever van het programma dienstverlening is de gemeentesecretaris. Onderdeel van deze organisatievorm is het project E-diensten. Dit project is opgezet om Edienstverlening voor een aantal producten via een generieke informatievoorziening respectievelijk fronten midoffice te realiseren. Een en ander is weergegeven in het dat is afgebeeld in figuur 5. Programma E-dienstverlening Programmamanager Programma-assistent

Programmacontroller

Communicatie

Project E-diensten Projectleider Stroomlijn

Projectteam E-diensten

Deelproject Klantcontact Deelprojectleider

Deelproject Zorgloket Deelprojectleider

Deelproject Ruimtebeheer Deelprojectleider

Deelproject FIN/WOZ Deelprojectleider

Figuur 5: organigram programma E-dienstverlening • Organisatie E-dienstverlening E-dienstverlening voorziet in de afstemming tussen de volgende activiteiten: Basisregistraties, Applicatiebeheer, Document management, E-diensten, ICT-beheer/I&A en Burgerservicenummer en het programma dienstverlening. Dit met het oog op realisatie van de doelstellingen zoals vastgelegd in het beleidsdocument “I-visie” en natuurlijk ook het programma dienstverlening uit het collegeprogramma 2006 - 2010. In het kader van E-dienstverlening bestaat nauw contact met het project E-diensten (wekelijks) en vindt tweemaal per maand een programmaoverleg plaats met de projectleiders van alle projecten die relevant zijn voor E-dienstverlening. Belangrijkste agendapunten zijn de overall planning en de bewaking van de samenhang (randvoorwaarden) tussen de verschillende (deel)projecten. Eventuele knelpunten en


94


beoogde oplossingen worden bij dit overleg ingebracht en besproken. De voortgang en eventuele dilemma’s worden besproken tijdens het wekelijkse DT (overleg directeuren). • Project E-diensten Het project E-diensten maakt onderdeel uit van E-dienstverlening. De projectleider rapporteert rechtstreeks aan de programmamanager E-dienstverlening. Het project bestaat uit een adviesgroep Stroomlijn en de vier deelprojecten Klantcontact, Financiën/WOZ, Ruimtebeheer en Zorgloket. Stroomlijn richt zich met name op de aanschaf en ingebruikname van de fronten midoffice voorzieningen en de deelprojecten zorgen er voor dat de organisatie op de edienstverlening wordt voorbereid, zoals het vereenvoudigen van aanvraag- en werkprocessen. Zowel Stroomlijn als de projectleiders van de deelprojecten (projectteam Deelprojecten) komen al naar gelang de behoefte één à twee keer per maand bijeen. De samenhang wordt bevorderd doordat Stroomlijn functioneert als klankbordgroep voor de ‘O-kant’ en het projectteam Deelprojecten als klankbord voor de ‘I-kant’ van het project Ediensten. Dit wordt bevorderd doordat de projectleider E-diensten tevens voorzitter is van zowel Stroomlijn als het projectteam Deelprojecten (linking pin). Hierdoor wordt bewerkstelligd dat de generieke front-/midoffice voorziening toepasbaar is en blijft voor de gewenste wijze van werken en vice versa. Voor het project E-diensten geldt dat het minimaal voor de volgende producten Edienstverlening moet voorbereiden en regelen, te weten: lichte bouwvergunning, melding openbaar gebied, informatieaanvraag, aanvraag bijzondere bijstand, GBA uittreksel, inzage taxatiegegevens en bezwaarschrift WOZ. Niet alle producten maken deel uit van de aanbesteding Midoffice Suite. Voor die onderdelen die wel onderdeel zijn van de aanbesteding willen wij E-dienstverlening van ‘voor naar achter’ regelen. Ondersteund door de frontoffice en de midoffice en daar waar relevant inclusief de koppeling met de backoffice. • Overige activiteiten Hieronder volgt een overzicht van ontwikkelingen met betrekking tot de andere activiteiten die relevant zijn voor E-dienstverlening. Voor de projecten Basisregistraties en Burgerservicenummer is een plan van aanpak beschikbaar en staan we in de startblokken. Voor de realisatie van de basisregistraties zoeken we nog naar de juiste ondersteuning door informatie en communicatietechnologie. Gedacht wordt aan een datadistributievoorziening en/of aan de inzet van met name het gegevensmagazijn (dat dan wel zowel administratieve als geometrische gegevens moet bevatten) en de broker uit de midoffice. Bij het project DocMan ligt het accent in eerste instantie op de invoering van DSP en het verbeteren van het gebruik van DocMan door middel van opleiding. Vervanging van DocMan is verschoven naar 2007. Reden is dat de gemeente Alphen aan den Rijn eerst de huidige wijze van werken op het gebied van de documentaire informatie wil verbeteren en via een pilot (Bijzondere bijstand) ervaring op willen doen met het werken via digitale dossiers. Daardoor wil de gemeente zich ook beter voor kunnen bereiden op de aanschaf en implementatie van een nieuw DMS en dat optimaal te kunnen gaan gebruiken.


95


Tevens loopt er een groot project Vervanging Infrastructuur Alphen aan den Rijn (VIA). Doel van dat project is vervanging van de gehele technische infrastructuur ten einde te gemeentebreed kunnen werken onder Citrix en met de nieuwe officebundel. De vervanging is begin juli 2006 afgerond. Deze wordt direct opgevolgd door een opleidingstraject voor de gehele organisatie. Het project Startpagina heeft als doel om alle medewerkers na het opstarten van de computer 1 pagina te tonen waarmee ze een overzicht krijgen van alle applicaties, informatie/nieuws, belangrijke/veelgebruikte functionaliteiten bijvoorbeeld postbak in of werkvoorraad, links naar favoriete sites, links naar onderhanden dossiers, mededelingen n dergelijke die ze nodig hebben voor de uitvoering van hun werk. Deze informatie en functionaliteiten worden geïntegreerd, transparant en gepersonaliseerd aangeboden. Wij zoeken naar een oplossing om dit mogelijk te maken. Project Facilitaire diensten heeft als doel om net als voor de publieke dienstverlening Edienstverlening mogelijk te maken voor interne dienstverlening. Daarvoor willen wij gebruik maken van de E-loket Suite van SmartSite voor het frontoffice deel en willen we op termijn ook aansluiten op de midoffice voorziening. 8.3.2 Meer- en minderwerk Frontoffice (FO) Voor wat betreft de functionaliteiten die in het onderhavige Bestek onder ‘frontoffice’ worden aangemerkt, overweegt de gemeente Alphen aan den Rijn reeds een voorziening in de vorm van de zogeheten E-loket Suite van leverancier Seneca. Deze E-loket Suite maakt onderdeel uit de nieuwste versie van het CMS SmartSite 5.1.(versie d), welke thans geïmplementeerd wordt. Bijzonder aandachtspunt is dat het midoffice dan voor wat betreft de onderdelen die niet tot het ‘frontoffice’ worden gerekend, naadloos moet aansluiten op het frontoffice van Alphen aan den Rijn, te weten de eerder genoemde E-loket Suite van Seneca. Dit betreft minimaal zaken als webintake, authenticatie, prefill, statusinformatie en opvragen overige informatie. Product/dienstencatalogus (PDC) Daarnaast zal de gemeente Alphen aan den Rijn mogelijk de (1P) product/dienstencatalogus functionaliteit niet afnemen maar een (3P) koppeling met de eigen product/dienstencatalogus, te weten die van Seneca. Document management (DMS) Ten slotte zal de gemeente Alphen aan den Rijn mogelijk de (1P) document management functionaliteit niet afnemen maar eventueel een (3P) koppeling met het eigen DMS. Het betreft hier dan een (tijdelijke) koppeling met DocMan van Circle Software, aangezien de gemeente Alphen aan den Rijn dan waarschijnlijk in de loop van 2007 een nieuw ‘zwaar’ DMS zal aanbesteden.


96


8.3.3 Extra’s Generieke applicatie Alphen aan den Rijn is voornemens het product ‘meldingen openbare ruimte’ volledig te realiseren met behulp van de functionaliteiten van de Midoffice Suite (dit is een zogeheten ‘generieke applicatie’) en daarbij geen gebruik te maken van een backoffice applicatie. Dit in tegenstelling tot gemeenten waarbij voor dit product een koppeling met een backoffice applicatie vereist wordt. Alphen aan den Rijn verzoekt Inschrijver dan ook aan te geven op welke wijze en tegen welke kosten dit product tot stand kan worden gebracht middels een dergelijke generieke applicatie. Voor melding openbaar gebied geldt dat deze als applicatieloos product geheel door de frontoffice (Smartsite) en midoffice afgehandeld moet kunnen worden. Wat betreft melding openbaar gebied moet het huidige Meldingen Afhandel Systeem van Oranjewoud overbodig worden. Dat betekent ook dat de inhoud van het systeem moet kunnen worden overgezet/geconverteerd naar het nieuwe systeem. Het nieuwe systeem dient een duidelijke verbetering te zijn ten opzichte van het oude in termen van gebruikersvriendelijkheid en mogelijkheden om managementrapportages te genereren. De functionaliteit die relevant is voor meldingen openbaar gebied moet door de frontoffice (via Smartsite) en de midoffice overgenomen kunnen worden. Overigens heeft de ICTU inmiddels ook een formulier voor melding openbaar gebied opgeleverd. Deze moet eveneens in gebruik genomen kunnen worden en gekoppeld kunnen worden met de midoffice. Vanuit de midoffice moet via de website resp. mijn loket ook statusinformatie aan de klant teruggegeven kunnen worden. Ook voor het maken van afspraken heeft de gemeente Alphen aan den Rijn geen specifieke backoffice applicatie. Zij verwacht dat het maken van afspraken opgelost kan worden in de generieke applicatie waarmee ook de meldingenadministratie wordt gevoerd. Dit vereist dan wel koppeling met het frontoffice (welke dus mogelijk met de E-loket Suite van Seneca wordt ingevuld) en de backoffice applicatie waarin de reserveringen van ruimten worden geregeld. (Prequest). Producten Voor wat betreft de op te leveren producten geldt dat Alphen aan den Rijn een bestuurlijke toezegging heeft gedaan om voor de volgende producten E-dienstverlening te realiseren te weten: bijzondere bijstand, binnengemeentelijke verhuizing, lichte bouwvergunning, informatieaanvraag, melding openbaar gebied, inzage taxatiegegevens en indienen bezwaarschrift WOZ. Bijzonder aandachtspunt is dat de producten bijzondere bijstand, informatieaanvraag, inzage taxatiegegevens en indienen bezwaarschrift WOZ niet in de top-7 van de gezamenlijke aanbesteding voorkomen en dus specifiek voor de gemeente Alphen aan den Rijn gerealiseerd moeten worden. Daarbij geldt dat het product informatievraag bij de Initiële implementatie wordt meegenomen. Voor de overige producten wil zij de toezegging dat zij deze na de oplevering van de top-7 en de informatieaanvraag zelf in eigen beheer kan realiseren.


97


Aandachtspunten bij deze producten zijn: -

De informatieaanvraag betreft een zogeheten ‘backoffice-loos’ product. Dit product moet dus geheel door de frontoffice van Seneca (E-loket Suite) en de midoffice ondersteund worden, van E-aanvraag tot en met de afhandeling en het verstrekken van statusinformatie bij meer complexe vragen.

-

Voor inzage taxatiegegevens en indienen bezwaarschriften maakt de gemeente Alphen aan den Rijn al gebruik van een webtoepassing van Gouw IT met identificatie van de klant door een combinatie van NAW-gegevens, sofinummer en nummer aanslag. In de backoffice draait het Heffingensysteem van Gouw IT. De klant kan de gegevens inzien op een database die bij Gouw IT draait. Deze worden via filetransfer periodiek bijgewerkt vanuit het Heffingensysteem en vice versa. Op termijn moet deze E-dienstverlening ondersteund kunnen worden door de frontoffice (SmarSite) en de midoffice, inclusief. koppeling met Heffingensysteem.

-

Voor bijzondere bijstand geldt dat wij een formulier hebben ontwikkeld waarvoor de ICTU met inzet van de formulierenmachine een E-formulier gaat maken. Dit formulier moet opgepakt kunnen worden door de midoffice en doorgezet kunnen worden naar het backoffice systeem GWS4all en statusinformatie terug te leveren aan de klant via de website respectievelijk Mijn Loket.

Voor wat betreft de producten die bestuurlijk zijn toegezegd en wel zijn opgenomen in de top7 van de collectieve aanbesteding zoals de lichte bouwvergunning en melding openbaar gebied gelden de volgende bijzondere aandachtspunten voor Alphen aan den Rijn: -

Voor de lichte bouwvergunning wordt overwogen om gebruik te gaan maken van het digitaal bouwloket. Dus moet het mogelijk zijn om een aanvraag die via dat loket binnenkomt te koppelen met de midoffice en door te zetten naar BWT4all en statusinformatie terug te leveren aan de klant via de website respectievelijk Mijn Loket.

Basisregistraties De gemeente Alphen aan den Rijn is gestart met de opbouw van de authentieke basisregistraties adressen, gebouwen en personen. Om het referentiebestand op te bouwen en schoon te houden wil de gemeente gebruik maken van een beheertool. Gedacht wordt aan de oplossing van Vicrea. Om de gegevens vervolgens beschikbaar te stellen voor gebruik (datadistributie) wil de gemeente Alphen aan den Rijn gebruik maken van de midoffice en dan waarschijnlijk met name het gegevensmagazijn en de broker. Ook voor wat betreft de presentatie van geo-informatie via de website wil de gemeente gebruik maken van een oplossing van Vicrea. Bijzonder aandachtspunt is dat de gemeente Alphen aan den Rijn voor de distributie van haar basisgegevens dus gebruik wil maken van het midoffice en met name het gegevensmagazijn en de broker. Dit betekent dat de beheertool, waarschijnlijk Vicrea, aan moet kunnen sluiten op de midoffice. Daarbij geldt dat ook wordt overwogen om een oplossing van Vicrea in te zetten voor het ontsluiten van geo-informatie via de website.


98


Facilitaire diensten De gemeente Alphen aan den Rijn is gestart met een project om ook interne dienstverlening te verbeteren en ook daarvoor E-dienstverlening mogelijk te maken. Waarschijnlijk wil zij daarvoor gebruik maken van de E-loket Suite van Seneca. Bijzonder aandachtspunt is dat de gemeente Alphen aan den Rijn op termijn het midoffice ook hiervoor in wil zetten en backoffice applicaties aansluiten zoals systemen voor de helpdesk, vergaderruimten boeken (Prequest of ClientProof), personeelsinformatie en dergelijke.


99


8.4

Gemeente Delft

De gemeentespecifieke bijlage van de gemeente Delft bestaat uit een tweetal onderdelen. Het eerste onderdeel (paragraaf 8.4.1) bevat relevante achtergrondinformatie over de gemeente Delft, waaronder een beknopte schets van de gemeente en de visie en ambities ten aanzien van (elektronische) dienstverlening, alsmede een beschrijving van de huidige situatie en de actuele ontwikkelingen. Het tweede onderdeel (paragraaf 8.4.2) bevat een beschrijving van het eventuele meer- en minderwerk zoals besproken in hoofdstuk 6. 8.4.1 Algemene informatie Introductie Delft, een stad met ruim 95000 inwoners is centraal gelegen in de Randstad tussen Den Haag en Rotterdam. Het is middelgrote stad met een compleet voorzieningenpakket en een monumentale, historisch bepaalde binnenstad. Nergens vindt u binnen loopafstand zoveel internationaal aansprekende cultuurhistorische waarden als in Delft: Delfts blauw, Johannes Vermeer, de band met het Huis van Oranje en de VOC. Maar Delft is meer dan alleen verleden. Delft is een bruisende hedendaagse stad die ook verrassend veel nieuws biedt. De stad is rijk aan veel kennisintensieve bedrijven en instellingen. Zie www.gemeentedelft.info. Visie en ambitie (elektronische) dienstverlening In de komende jaren wil Delft een forse verbeterslag maken. Met een programmatische aanpak gaat de gemeente haar dienstverlening vraaggericht inrichten volgens het principe van het klantcontactcentrum (KCC). Dit is een vorm van dienstverlening waarbij burgers en bedrijven ervaren dat vragen zoveel mogelijk direct worden afgehandeld aan balie, telefoon en internet. Burgers kunnen terecht bij één telefoonnummer en één website voor verschillende producten en diensten. Als dit is gerealiseerd, ervaart de klant dat hij in één keer goed en zo snel mogelijk wordt geholpen, tegen gelijke of lagere kosten. Huidige situatie Delft heeft, met de verandering van de gemeentelijke organisatie (NEON), een ambitie geformuleerd met accenten op externe oriëntatie en het optreden als één organisatie. Die koers heeft geleid tot het inrichten van één publieksbalie en een infopunt Stadsbeheer. Inmiddels kent Delft ook één gemeentelijke website waarop de digitale diensten worden aangeboden. Daarnaast heeft het meerjarenplan Dienstverlening een aantal servicenormen opgeleverd. Delft is op de goede weg, maar het doel is nog niet bereikt. Voor de burger is het niet altijd duidelijk waar hij terecht kan met zijn vragen aan de gemeente en wat hij kan verwachten. De gemeente kent nog steeds drie ‘hoofdingangen’ – de Publieksbalie aan de Phoenixstraat, het infopunt Stadsbeheer en de balies van de sector WIZ – en een veelheid aan andere balies en telefoonnummers, met verschillende tijden waarop ze open of bereikbaar zijn en verschillende werkwijzen. Bovendien zijn systemen nog onvoldoende gekoppeld. Dat betekent bijvoorbeeld dat een doorgegeven adreswijziging niet bij alle afdelingen bekend is. Bij de gemeente Delft werken ongeveer 1700 medewerkers. Het gemeentepersoneel werkt sinds de reorganisatie van 1 maart 2000 in clusters. Commercieel vertrouwelijk

100


Actuele ontwikkelingen Delft streeft ernaar de dienstverlening voortdurend te verbeteren en investeert daarin al fors via het Programma Dienstverlening. De resultaten zijn er dan ook naar. Het college neemt de (wensen van de) steeds beter geïnformeerde en mondige burger serieus. Daarom is dienstverlening, en de manier waarop de organisatie die realiseert een speerpunt. De bestuurlijke vernieuwing, met de invoering van het duaal bestel, heeft geleid tot een steviger aandacht voor de diensten die de gemeente levert en de verplichting om daarover verantwoording af te leggen. In het openbare debat is een duidelijke tendens waarneembaar om het begrip dienstverlening ruim te interpreteren. Sinds NEON is het besef gegroeid dat externe oriëntatie meer is dan de blik naar buiten wenden en de organisatie vraaggericht inrichten. Delft moet de processen in de organisatie blijven afstemmen op de wensen van de burger en duidelijker zijn over wat deze kan verwachten. Het resultaat van de uitvoering van dit plan moet een actueel beeld zijn van wat de klant wil (‘de burger centraal’) en het daarop afstemmen van het eigen niveau van dienstverlening. Dit binnen de grenzen van weten regelgeving en de (financiële) mogelijkheden van de organisatie. 8.4.2 Meer- en minderwerk De gemeente Delft zal mogelijk de (1P) product/dienstencatalogus component niet afnemen maar eventueel een (3P) koppeling met de eigen product/dienstencatalogus, te weten die van Green Valley. Dit geldt ook voor de functionaliteiten vraaggeleiding. Bovendien zal de gemeente Delft eventueel de (1P) zoekfunctionaliteit niet afnemen maar mogelijk een (3P) koppeling met de eigen zoekmachine, te weten die van Verity. Daarnaast zal de gemeente Delft mogelijk de (1P) document management functionaliteit niet afnemen. In plaats daarvan is Delft eventueel geïnteresseerd in een (3P) koppeling met het eigen DMS van Hummingbird. Ten slotte zal de gemeente Delft eventueel de (1P) component beperkt relatiebeheer (CRM) niet afnemen. In plaats daarvan is Delft mogelijk geïnteresseerd in een (3P) koppeling met het eigen, relatief eenvoudige CRM-pakket PerfectView. 8.4.3 Overige informatie Huidig midoffice De gemeente Delft heeft reeds vele processen gedigitaliseerd. Voorbeelden hiervan zijn een aantal producten uit de top-7: alle GBA uittreksels, binnengemeentelijke verhuizing, inzameling grofvuil en melding openbaar gebied. Ook op het gebied van B2B (business-tobusiness) oplossingen is Delft vooruitstrevend. Voorbeelden hiervan zijn: verhuizing door woningcorporaties, elektronische aannemersdagkaart en online begraafplaatsenagenda voor begrafenisondernemers. Hierbij is steeds gebruik gemaakt van het eigen, intern ontworpen en geprogrammeerde midoffice ‘GEM’. Commercieel vertrouwelijk

101


Vervolg producten De gemeente Delft wil direct na het realiseren van de top-7 producten uit dit bestek verder gaan met het herinrichten en digitaliseren van andere producten en processen. Hierbij wordt momenteel concreet al gedacht aan: -

Subsidies: aanvragen subsidies voor bedrijven, instellingen en burgers. Er is nog geen backoffice applicatie voor dit product, daartoe zal de generieke applicatie van de Midoffice Suite worden ingezet.

-

Een aantal interne producten die door het cluster Middelen worden geleverd. Onder het cluster Middelen vallen onder andere de vakteams P&O, Financiën, Huisvesting en IT.

-

Omzetten van producten en processen uit GEM naar de nieuwe Midoffice Suite.

Herinrichten processen Het voornemen van de gemeente Delft gaat veel verder dan het digitaliseren van de bestaande processen. Vooral het herinrichten van processen met als doel efficiënter, effectiever en transparanter werken staat hoog in het vaandel. Bij de herinrichting van processen wordt gestreefd naar uniformiteit van processen (in werkwijze en beschrijven), optimaal gebruik maken van de functionaliteiten van de Midoffice Suite, gebruik van standaard servicenormen, gebruik maken van authentieke basisregistraties, etc. Hiertoe ontwikkelt Delft momenteel in samenwerking met EGEM een generieke methodiek ‘Herinrichten gemeentelijke processen’. Basisregistraties Er wordt momenteel hard gewerkt aan de opbouw van authentieke basisregistraties in Delft. De meeste zijn inmiddels opgeschoond en adressen en gebouwen worden ook middels diverse koppelingen verspreid naar andere registraties. Om deze koppelingen gestructureerd te laten verlopen en ‘eenvoudig’ uit te breiden met onder andere personen is er een project gestart voor de aanschaf van een datadistributievoorziening. Dit project is inmiddels in de fase beland waarin de toegestuurde offertes worden beoordeeld.


102


8.5

Gemeente Ede

De gemeentespecifieke bijlage van de gemeente Ede bestaat uit één onderdeel dat relevante achtergrondinformatie bevat over de gemeente Ede (paragraaf 8.5.1), waaronder een beknopte schets van de gemeente en een beschrijving van de huidige situatie en de actuele ontwikkelingen. 8.5.1 Algemene informatie Introductie De gemeente Ede heeft 106.000 inwoners en ruim 1000 ambtenaren. De gemeentelijke organisatie bestaat uit 5 autonome sectoren en een redelijk ontwikkelde horizontale structuur om de samenhang aan te brengen. Voor meer informatie zie de website www.ede.nl. Huidige situatie Ede is een zeer pragmatisch ingestelde gemeente. Er bestaat geen expliciet dienstverleningsbeleid en ook geen organisatie onderdeel dat hiervoor verantwoordelijk is. De organisatie is behoorlijk mean en lean en de capaciteit om in te zetten op bijvoorbeeld digitale dienstverlening is zeer beperkt. Ede heeft als eerste gemeente in Nederland concernbreed een kennissysteem (Vraag en Antwoord) voor burgers ingevoerd en een email response systeem waar alle afzonderlijke publieksbalies gebruik van maken. Ede heeft al in 2004 een basis gelegd voor de inrichting van digitale dienstverlening door de implementatie van een MO en een digitaal loket. Actuele ontwikkelingen Ede heeft in 2004 een meerjarig innovatieprogramma ingesteld met een budget van 840.000 euro voor 3 jaar (www.edegelderland.nl/info.asp?id=2856). Er zijn twee belangrijke documenten over de inzet van de gemeente op digitale dienstverlening: de jaarprogramma’s 2004 en 2005. Deze zijn te vinden op www.edegelderland.nl/info.asp?id=2948.


103


8.6

Gemeente Nieuwegein

De gemeentespecifieke bijlage van de gemeente Nieuwegein bestaat uit twee onderdelen. Het eerste onderdeel (paragraaf 8.6.1) bevat relevante achtergrondinformatie over de gemeente Nieuwegein, waaronder een beknopte schets van de gemeente en de visie en ambities ten aanzien van (elektronische) dienstverlening, alsmede een beschrijving van de huidige situatie en de actuele ontwikkelingen. Het tweede onderdeel (paragraaf 8.6.2) bevat een beschrijving van het eventuele meer- en minderwerk zoals besproken in hoofdstuk 6. 8.6.1 Algemene informatie Introductie Nieuwegein is een gemeente met ca. 62.000 inwoners en 550 medewerkers. De gemeentelijke organisatie is opgedeeld in sectoren. Alle gemeentelijke taken worden zelfstandig uitgevoerd, alhoewel steeds meer in regie met derden gebeurt. Uitgebreider informatie over de gemeente Nieuwegein is te vinden op www.nieuwegein.nl. Visie en ambitie (elektronische) dienstverlening Nieuwegein is nog volop in ontwikkeling. Naast de bouw van enkele nieuwe (deel)wijken is eer een groot project voor de herstructurering van het stadshart. In 2010 zal daarin een nieuw stadshuis gerealiseerd worden. Opmerkelijk daarin me betrekking tot digitalisering is dat het nieuwe pand 25% kleiner is dan het huidige. Door regionalisering en privatisering is minder ruimte nodig, maar ook flexibel werken wordt gestimuleerd. Bovendien neemt de fysieke archiefruimte met circa 75% af. Dit vraagt om verregaande digitalisering; niet alleen voor burgers en bedrijven, maar ook voor de bedrijfsvoering, waarbij het kernwoord ‘regie’ is. Nieuwegein heeft een meerjarig programma ‘Nieuwegein Kiest op Maat’. In steekwoorden zijn de inhoudelijke ambities: -

Voor het sociale leven in Nieuwegein: ontmoeten, kennen, kunnen en steunen.

-

Voor het imago van Nieuwegein: bekend en gewaardeerd.

-

Voor de fysieke leefomgeving in Nieuwegein: schoon, heel en veilig.

De ambities met betrekking tot verantwoordelijkheids- en rolverdeling zijn: -

Voor de rol van de gemeente: doen wat moet. faciliteren en samenwerken.

-

Voor de rol van de burger: eigen verantwoordelijkheid en ruimte voor initiatief.

Daarnaast vindt de gemeente Nieuwegein het vanzelfsprekend dat zij in haar beslissingen en in haar werk niet alleen naar het heden en binnen onze gemeentegrenzen kijkt, maar ook naar de toekomst en naar de wereld om zich heen. Dit betekent dat de gemeente Nieuwegein duurzaamheid en internationale ontwikkelingen in haar afwegingen betrekt. Bovendien wil zij investeren in samenwerking met de Lekstroomgemeenten (te weten Houten, IJsselstein, Lopik en Vianen) en in het Bestuur Regio Utrecht. Commercieel vertrouwelijk

104


Voor de digitale dienstverlening is het project EDDIE in het leven geroepen. Bij dit project ligt het accent op de verbetering van de gemeentelijke dienstverlening en niet op het digitaliseren van de werkprocessen. Reden hiervoor is dat de term Digitaliseren teveel de indruk geeft dat het gaat om een project met een automatiseringsfocus. Dat is niet de opzet. Het doel is immers niet digitaliseren van werkprocessen maar om te komen tot excellente interne en externe dienstverlening. Digitaliseren is daarvoor slechts een middel. Digitaliseren biedt echter ook de mogelijkheid om de verbetering van de dienstverlening te combineren met een verhoging van de efficiency van het ambtelijke apparaat en daarmee een verlaging van de kosten te realiseren. Het project EDDIE levert daarom een structurele bijdrage van 300.000 Euro aan de concerntaakstelling op de overhead van Nieuwegein Kiest. Vanuit deze context is de volgende doelstelling geformuleerd: optimaliseer de gemeentelijke dienstverlening zodanig dat de kwaliteit, snelheid en flexibiliteit worden verhoogd tegen lagere kosten. Op basis van die doelstelling is een aantal subdoelstellingen geformuleerd: -

Een product wordt in principe direct geleverd;

-

Het digitale gemeenteloket is in 2010 7 x 24 uur geopend;

-

De doorlooptijd van de werkprocessen wordt met minimaal 30% verminderd;

-

De administratieve lastendruk (afschaffen vergunningen, aanvragen en formulieren) wordt met minimaal 20% verminderd;

-

Het digitale gemeenteloket is voor iedereen beschikbaar;

-

Alle producten die in technische en in logische zin in aanmerking komen voor digitalisering, moeten in 2010 digitaal beschikbaar zijn;

-

Realiseer een structurele besparing van 300.000 Euro;

-

Realiseer een formatieve besparing van circa 30 FTE.

-

In 2010 heeft de gemeente Nieuwegein bij http://advies.overheid.nl/continu/gemeente/ een de top 20 notering.

Huidige situatie • Applicatiearchitectuur Alleen de meest relevante applicaties zijn vermeld. -

Financiële Systemen FIS4all WBU4all DIS4FIS

-

2.13.2 2.13.2 1.3

Financiële Administratie Tijdregistratie Scanning facturen

Persoonsinformatievoorziening PIV4all DIS4PIV Kas4all


3.40.04 3.24 3.2

Gemeentelijke Bevolkingsadministratie Scanning en Imaging Kas- en Betalingstransacties 105


Vastgoed BGB4all BWT4all HIS4all/VGS4all

-

5.2.0008 4.6.02 1.2

Sociale Dienst administratie Proces en Kennisondersteuning Elektronisch klantendossiers

2.0.10

Documentgenerator voor alle Centric pakketen

13.11p 5.01j 2.4 200448 3.5

Meldingen openbaar gebied Groen en Rioolbeheer Wegbeheer registratie systeem Afvalregistratie Grafisch Informatie Systeem

11.0.3 11.3

Milieu Bodem informatie systeem Milieu Grafisch Informatie Systeem

4.32C 7.5

Facilitair planningssysteem Helpdeskpakket automatisering

Milieu StraMis/StrBis StraGis

-

Leerplichtigenadministratie

Beheer RS8 Melddesk RS8 Beheer DHVWegbeheerSys. ARIS2000 Flexiweb

-

6.3.999

Documentgenerator DOC4all

-

Begraafplaatsenadministratie

Werk, Inkomen en Zorg GWS4all PKO4all DIS4GWS

-

2.40.001

Leerplicht LLA4all

-

Basisregistratie Adressen en Gebouwen Bouw- en Woningtoezicht Heffingen / Gemeentelijke Belastingen / WOZ

Begraafplaatsen en Crematoria BPA4all

-

6.5 6.5 6.5 / 4.00.00

Facilitair Planon Magic

• Technische Infrastructuur Unix omgeving -

Hardware HP 9000 / RP5470 (wordt RISC Processor PA8900 en Itanium based) Back-up met LTO library Storage XP48

-

Software Operating System HP-UX 11iv1 (11.11) (wordt 11iv2) Oracle versie 9.2.0.6.0 (wordt 10Gr2) HP Dataprotector 5.1 (wordt 6)


106


Microsoft Server -

Hardware Compaq Proliant DL Serie Back-up op een LTO-Ultrium tape robot HP EVA 3000 SAN HP NAS4000 NAS Netapp F825 NAS

-

Software Microsoft Windows 2000 Microsoft Windows 2003 Compaq Cluster software HP Dataprotector 5.1 (wordt 6) MS exchange 2003 SP2

Werkstations -

Standaard werkplek HP DC7600 SFF Intel® Pentium 4 HT 3.00 Ghz 512 MB intern geheugen 40 GB extern geheugen (S-ATA) Onboard Sound Onboard Netwerk (10/100/1000) Onboard Video (Intel® Extreme Grafische Controller)

-

CAD-werkplek HP XW6200 Dual Intel® XEON Pentium 4 HT 3.40 Ghz 2048 MB Intern geheugen 2x 80 GB extern geheugen (S-ATA) NVIDIA Quadro NVS 285,128MB, PCIe Card Onboard Netwerk (10/100/1000)

-

Laptops HP NC6120 corporate business notebook HP NC6320 corporate business notebook

-

Beeldschermen HP 17 inch TFT HP 19 inch TFT HP 21 inch TFT HP 23 inch TFT

-

Scanners HP Scanjet 5590


107


Printers Oce PP15 Oce PP22 Oce WP36 Oce OP20 Oce OP25 Oce OP35 Oce 3145 Oce VP 2060 Oce VP 2090 Oce WP31C Oce CS230 Oce CPS700 Oce TDS600

-

Diversen HP IPAQ HX4700 (High end) HP IPAQ HX2490 (Low end) Plextor 48*12*48 IDE CD-writer intern Canon Camera

-

Software Microsoft Windows 2000 Workstation SP4 Nederlands (wordt Windows XP SP2) Internet Explorer 6.0 (wordt 6.1) MDAC 2.5 (wordt 2.7) Microsoft Office 2000 (wordt Office 2003) Microsoft Outlook XP (wordt Outlook 2003)

-

Database koppeling Borland engine versie 5.11 t.b.v. Centric Applicaties (gaat vervallen) Omega 3.0 plugin (t.b.v. Microstation en Geooutlook) Oracle cliënt voor versie 8.1.7 voor 2k (Net8 versie 8.1.7)

Actuele ontwikkelingen Nieuwegein maakt de omzwaai van groeikern naar beheersgemeente. De huidige grote infrastructurele projecten zullen in de komende jaren ten einde lopen. Daarnaast is de verwachting dat een en ander steeds meer in regioverband opgepakt gaat worden. Op automatiseringsgebied wordt bekeken of de gemeente Nieuwegein samen met de gemeente IJsselstein één ICT-organisatie kan gaan vormen. Tevens is er de mogelijkheid dat de gemeente Nieuwegein in 2007 de automatisering van een regionale Sociale Dienst in oprichting gaat verzorgen. Binnen Nieuwegein is sprake van basisregistraties. In de volgende applicatie(s) (of maatwerk) worden de bronbestanden onderhouden: -

Natuurlijke Personen: PIV4All, Adressen: BGB4All (ADR4All) Gebouwen: BGB4All


108


8.6.2 Meer- en minderwerk De gemeente Nieuwegein zal mogelijk de (1P) product/dienstencatalogus functionaliteit niet afnemen en eventueel een (3P) koppeling met de eigen product/dienstencatalogus wel. Deze is echter nog niet bekend (zie bijlage 8.10).


109


8.7

Gemeente Zoetermeer

De gemeentespecifieke bijlage van de gemeente Zoetermeer bestaat uit een drietal onderdelen. Het eerste onderdeel (paragraaf 8.7.1) bevat relevante achtergrondinformatie over de gemeente Zoetermeer, waaronder een beknopte schets van de gemeente en de visie en ambities ten aanzien van (elektronische) dienstverlening, alsmede een beschrijving van de huidige situatie en de actuele ontwikkelingen. Het tweede onderdeel (paragraaf 8.7.2) bevat een beschrijving van het eventuele meer- en minderwerk zoals besproken in hoofdstuk 6. Het derde onderdeel ten slotte (paragraaf 8.7.3) bevat een beschrijving van de extra’s zoals besproken in hoofdstuk 6. 8.7.1 Algemene informatie Zoetermeer is een eigentijdse stad op een steenworp afstand van Den Haag, Leiden en Rotterdam. Ze beschikt over uitgebreide voorzieningen op sportief en recreatief gebied, met landelijke trekkers als het skiparadijs SnowWorld en het multifunctionele ijscentrum PWA Silverdome. In het Stadshart vinden we een uitstekend geoutilleerd regionaal winkelcentrum, met even verderop de sfeervolle historische Dorpstraat. Voor de jeugd zijn grootschalige uitgaansgelegenheden gerealiseerd, terwijl ook de cultuurminnende bezoekers niet worden vergeten in het toonaangevende stadstheater en moderne bioscoopcomplex. Dit is slechts een kleine greep uit de grootsteedse voorzieningen die passen bij een stad met meer dan 116.000 inwoners. Kerngegevens per 1 april 2006 Aantal inwoners: Aantal woningen: Oppervlakte in hectare: Bevolkingsdichtheid per km² land: Woningdichtheid per km² land: Aantal bedrijven: Aantal arbeidsplaatsen: Aantal arbeidsplaatsen ICT-sector: Beroepsbevolking: Aantal geregistreerde werklozen: Aantal scholen:

117.234 49.875 3.706 3.436 1.445 3.006 40.146 5.257 55.000 4.947 66

Een organigram van de gemeente Zoetermeer is bijgevoegd als figuur 6.


110


Figuur 6: organigram gemeente Zoetermeer Visie en ambities (elektronische) dienstverlening Centraal in het programma Burger en Bestuur staat het voornemen van het gemeentebestuur van de gemeente Zoetermeer dicht bij haar inwoners te staan. Een kernthema daarbij is het verlenen van een zo goed mogelijke dienstverlening. De gemeente wil haar dienstverlening tot stand brengen in samenspraak met inwoners, organisaties en instellingen. Daarnaast wil de gemeente de inwoners van Zoetermeer goede dienstverlening voor een betaalbare prijs bieden.


111


De hele dienstverleningsvisie van 13 juni 2006, zoals die aan het college van B&W is voorgelegd, is te vinden op de website. Deze visie schetst de koers die de gemeente Zoetermeer voor de externe dienstverlening heeft ingezet en verder wil uitzetten. Huidige situatie Met een sterke positie als ICT koploper verwerft Zoetermeer een belangrijke plaats in de moderne informatiemaatschappij op lokaal, regionaal en landelijk niveau. Dit is uitgevoerd in het programma Zoetermeer ICT stad. Het Zoetermeerse programma concentreert zich op ICTprojecten op het gebied van zorg, onderwijs, bedrijfsleven, samenleving en infrastructuur. Denk hierbij bijvoorbeeld aan het mogelijk maken van een zeer snelle digitale infrastructuur tegen lage prijzen voor het Zoetermeerse bedrijfsleven, scholen en zorginstellingen, maar ook aan projecten op het gebied van onderwijs, zoals de Academie voor ICT Zoetermeer, ICT projecten op scholen en ICT-toepassingen binnen de zorg. DigiD is ingevoerd en de BNG-internetkassa wordt gebruikt. De gemeente maakt deel uit van het Egem project voorhoedegemeenten. Actuele ontwikkelingen De gemeente wil zelf het goede voorbeeld geven op ICT gebied door het realiseren van projecten op het gebied van digitale dienstverlening. Digitale dossiers en dienstverlening behoren tot de speerpunten van het collegeprogramma voor de periode 2006-2010. In deze periode moeten de volgende resultaten worden geboekt: De afname van digitale producten is toegenomen van 15% tot 30% van het totaal aantal afnamen. - Een burger levert in 90% van de contacten slechts éénmaal gegevens aan. - De klanttevredenheid over de gehele dienstverlening neemt toe van 6,7 naar 7,0. - De klanttevredenheid over de wijkposten neemt toe van 6,0 naar 7,0. -

Infrastructuur Gebruikers werkplek Elke standaard werkplek is uitgerust met een DELL PC. Onderstaand volgt een opsomming van een standaard gebruikers PC. Er kunnen afwijkende configuraties geïnstalleerd zijn, maar dit betreffen alleen uitgebreidere configuraties die noodzakelijk zijn voor het uitvoeren van de taken van de betreffende gebruiker. Uit het oogpunt van beheer voert de gemeente een windows policy waarbij de cliënt pc dicht staat. Dit wil zeggen dat elke eindgebruiker slechts leesrechten heeft op zijn harde schijf. Specifieke gebruikersrechten anders dan leesrechten moeten expliciet gedefinieerd worden. Het is de doelstelling van de Gemeente Zoetermeer zo minimaal mogelijk software op de cliënt pc te installeren. Mocht er toch software op de cliënt benodigd zijn dan wordt deze verspreid in de vorm van MSI pakketten middels SMS. Een standaard werkplek bestaat uit de volgende componenten en wordt door Automatisering ondersteund:


112


Product Standaard hardware Dell OptiPlex GX280 Pentium 4 520 2.8 Ghz Geheugen 512 Mb Interne disk 40Gb Filesysteem Floppy drive CD-Rom USB poorten 9 PINS seriële poort Parallel poort TCP/IP netwerk adapter Beeldscherm

Versie + bijzonderheden

Leverancier

Windows 2000 Professional Microsoft/Dell Computer NL 5.00.2195 Service Pack 3 Dell Computer Filesysteem C: Dell Computer NTFS Microsoft 1,44 Mb, station A: Dell Computer Station E: Aantal: 6 Aantal: 1 Aantal: 1 100BaseT 19” TFT screen, 1024X768 60Hz, true color Toetsenbord NL invoer, VS instelling Muis IntelliMouse Standaard software Versie + bijzonderheden Leverancier Office2000 Professional NL; SP3; zonder FrontPage Microsoft Outlook2000 SP 9.0.0.6627 Internet Explorer V6 SP1 (6.0.2800.1106) Plugins MacroMedia Flash 6.0.65.0 Shockwave 8.5.1 Quicktime ActiveX Plugin V6.0 Acrobat Reader V5.1.0 NL Adobe WinZip 9.0 SR1 EN WinZip Computing Workpace 3.0 Niche Software Proxy V4.0 McAfee Virusscan Enterprise 8.0.0 Network Associates SMS agent 2.0 Microsoft Platforms • Concernsystemen :

HP9000 server & HP-UX 11 i 64bit English

De concernsystemen worden ingezet als Oracle database servers: HP Unix met Oracle databases. Product HP9000 server Oracle RDBMS Uniface server software Standaard Unix shells TCP/IP protocol Journalled filesystemen MC/Serviceguard


Versie + bijzonderheden HP-UX 11 i 64bit English Oracle 9i/10g 64bit Enterprise Edition Versie 7 en hoger Posix, Bourne + Korne, OS afhankelijk OS afhankelijk VxFS, OS afhankelijk Unix clusteromgeving

Leverancier Hewlett-Packard Oracle Applicatieleverancier Hewlett-Packard Hewlett-Packard Hewlett-Packard Hewlett-Packard

113


• Kantoorautomatisering:

HP/Compaq ProLiant DL, vanaf Pentium III W2K Advanced Server 5.00 SP 3

De W2k systemen worden voornamelijk ingezet als applicatie en file servers. Kleinere databases worden met SQL Server geïmplementeerd. De volgende producten zijn geïnstalleerd en worden door Automatisering ondersteund: Product HP/Compaq ProLiant DL series vanaf Pentium III Microsoft Cluster software Internet Information Server (IIS) Compaq SAN NTFS SQL Server McAfee NetShield Terminal Server Mirrored internal OS disks TCP/IP protocol Compaq Insight Manager NetIQ Veritas Backup Exec Oracle client software Borland Database Engine

Versie + bijzonderheden Windows2000 Advanced Server 5.00 SP 3 OS afhankelijk OS afhankelijk

Leverancier Hewlett-Packard Microsoft Microsoft Microsoft

RA8000 OS afhankelijk 2000 4.5.1 OS afhankelijk OS afhankelijk OS afhankelijk OS afhankelijk Versie 5 Versie 9.0 Oracle 9 Versie 5.2

Hewlett-Packard Microsoft Microsoft Network Associates Microsoft Hewlett-Packard Microsoft Hewlett-Packard Albion Veritas Oracle Borland

De gemeente staat alleen toe dat software in de vorm van services op de W2K servers geïnstalleerd wordt. Het is niet mogelijk cliënt software op de servers te installeren. Databases • Concernsystemen:

Oracle databases, Oracle 9i/10g 64bit Enterprise Edition

Indien sprake is van het gebruik van Oracle databases kunnen alleen Unix systemen ingezet worden. Oracle databases op een W2K server omgeving zijn niet mogelijk. Door de toenemende implementaties van cliënt/server en three tier (werkplek + applicatieserver + database server) toepassingen worden de Unix servers in belangrijke mate alleen ingezet als database servers. Voorbeelden van cliënt/server toepassingen zijn GWS4all, BWT4all en FIS4all. Het gemeente GIS is een voorbeeld van een three tier toepassing.De gemeente ondersteunt Oracle cliënt software versie 9. Gebruik van eerdere versies Oracle cliënt software is niet mogelijk. De gemeente ondersteunt Borland database engine versie 5.2. Gebruik van eerdere versies Borland engine software is niet mogelijk • Kantooromgeving:

SQL Server databases, MS-SQL 2000 server

T.b.v. van ‘kleinere’ afdelingsdatabases wordt een MS-SQL 2000 server ingezet.


114


Insourcing De huidige frontoffice componenten CMS, WIS, PDC, RIS, GIS en Centric Midoffice worden gehost bij verschillende hosting partners. De Gemeente Zoetermeer heeft de intentie zelf de nieuwe frontoffice en midoffice componenten te hosten. Beveiligingsinfrastructuur Webmail.zoetermeer.nl

DMZ

SUN/Checkpoint-1 Firewall VPN Siemens VPN Centric

Internet SGS5400 ISA Server Proxy/firewall

Firewall

CoreSwitches

Gemeentelijk Netwerk

Document management (DMS) Binnen de afdeling BWT is een DMS geïmplementeerd t.b.v. afhandeling van bouwvergunningen. Hiervoor wordt gebruikgemaakt van een DMS oplossing van de leverancier OIS. Het DossierWeergave-sjabloon wat wordt gebruikt voor Bouw- en Woningtoezicht wordt gekenmerkt door toegesneden modeldossiers en de volledige integratie met BWT4all van Centric. Als onderliggende schil van dit systeem wordt een zeer beperkte functionaliteit van FileNet gebruikt. Het is de bedoeling om op termijn gemeentebreed één generiek (horizontaal) DMS te gebruiken. Om dit te realiseren is een project opgestart DIGIDOS waarin een DMS oplossing wordt gezocht voor de volgende domeinen: sociale zaken (WVG, WBB), facturen, persoonskaarten, foto’s, postregistratie en DIV-functionaliteit.


115


T.b.v. de registratie en afhandeling van post wordt gebruik gemaakt van DocMan van Circle Software. Tevens is in dit systeem het raadsinformatiesysteem (RIS) geïmplementeerd voor ondersteuning van de bestuurlijke besluitvorming. Het RIS bestaat uit een uitbreidingsmodule in DocMan en een Web component. Dit is een databank waarin de openbare gemeentelijke stukken van de Gemeente Zoetermeer kunnen worden geraadpleegd. Het gaat hier om de stukken die in de raadscommissies en de gemeenteraad zijn behandeld of binnenkort worden behandeld.

Figuur 7: DMS BWT Geo-informatiesysteem (GIS) De Gemeente Zoetermeer maakt momenteel gebruik van een geo-informatiesysteem (GIS) waarin diverse geografische en administratieve gegevens van verschillende systemen worden samengevoegd en op elkaar worden geprojecteerd volgens figuur 8. Het datawarehouse van dit GIS kan mogelijk als uitgangspunt dienen voor een gegevensmagazijn. Het GIS bestaat uit de volgende software componenten: Geodan MapXtreme 3.01, MapInfo Professional 7.5, GeoKey 3.2 en GeoSet, NedGraphics, ISIS, Oracle Spatial. Op dit moment zijn via internet de volgende kaarten raadpleegbaar: beeldende kunstobjecten, parkeergebieden, inzamellocaties voor afval, informatie over sonderingen en de risicokaarten.


116


Figuur 8 : geo-informatiesysteem (GIS) 8.7.2 Meer- en minderwerk Product/dienstencatalogus (PDC) De gemeente Zoetermeer zal mogelijk de (1P) product/dienstencatalogus functionaliteit niet afnemen maar een (3P) koppeling met de eigen product/dienstencatalogus, te weten die van Segment Interactieve Media (OPUS). 8.7.3 Extra’s Migratie De gemeente Zoetermeer biedt op dit moment de onderstaande producten / formulieren aan op haar website. De formulieren, die worden afgehandeld in het zakeninformatiesysteem, zijn door de medewerkers van de gemeente zelf ontwikkeld met een formulierengenerator van Centric. Van de Inschrijver wordt verwacht dat enkele formulieren in samenwerking met de medewerkers van de gemeente Zoetermeer worden gemigreerd naar de midoffice omgeving zodat kennisoverdracht plaatsvindt. De medewerkers van Zoetermeer moeten vervolgens zelfstandig in staat te zijn de overige formulieren te kunnen implementeren. -

Aanvraag informatiekraam Aanvraag visvergunning + aanvraag 5 visvergunningen Aanvraag sondering Aanvraag vergunning driehoeksborden Aanvraag tijdelijke ontheffing wegenverkeerswet Aanvraag eigen verklaring CBR Aanvraag vergunning buurtfeest/straatfeest Aanvraag kapvergunning Aanvraag standplaatsvergunning Aanvraag ventvergunning Aanvraag sticker reclamedrukwerk Aanmelding zwemlessen in Zoetermeer (backoffice: Recreatix, geen koppeling) Aangifte hondenbelasting (backoffice: GHS4ALL, geen koppeling)


117


De intentie van de gemeente Zoetermeer is om, na de Initiële implementatie, deze migratie ter hand te nemen. Daarnaast biedt de gemeente Zoetermeer momenteel nog de volgende mogelijkheden met betrekking tot elektronische dienstverlening, met behulp van het Centric MidOffice. De migratie van deze functionaliteiten dient bij de Initiële implementatie gerealiseerd te worden. •

Bouwaanvragen Inzage status bouwaanvraag. In de huidige Centric MidOffice omgeving is het mogelijk de status van ingediende bouwaanvragen online te kunnen inzien. Hierbij wordt gebruik gemaakt van een pincode. De pincode wordt op de ontvangst bevestigingsbrief bekend gemaakt aan de klant. Inzage lopende bouwaanvragen. Tevens is het mogelijk lopende bouwaanvragen op adres, postcode of wijk te bekijken. Hiervoor is geen identificatie benodigd. Voor de publicatie van de bouwaanvragen is een koppeling gerealiseerd met de backoffice appicatie BWT4all (via het gegevensmagazijn).

•

Koppeling met DDS4ALL Er is een koppeling gerealiseerd met DDS4ALL en de Centric MidOffice omgeving om het gegevensmagazijn te voorzien van updates van GBA gegevens.

• Afspraken De Gemeente Zoetermeer maakt voor het maken van afspraken met burgers gebruik van de BAVAK afsprakenmodule. Dit is een backoffice applicatie. Deze backoffice applicatie kan worden uitgebreid met de frontoffice Bavak ‘internet afsprakenmodule’ zodat het mogelijk is via internet afspraken voor een baliedienst te maken. Tegen het gebruik van deze frontoffice module zijn echter enkele bezwaren, met name op het gebied van security. Een mogelijke oplossing is om de frontoffice functionaliteit te realiseren met behulp van de functionaliteit van de Midoffice Suite. Het midoffice koppelt vervolgens weer met de BAVAK backoffice applicatie. Om dit mogelijk te maken is de gemeente Zoetermeer geïnteresseerd in een koppeling (via de broker) met het afsprakensysteem BAVAK. In dat kader vraagt de gemeente Zoetermeer Inschrijver om aan te geven op welke wijze en tegen welke kosten deze oplossing inclusief koppeling tot stand kan worden gebracht. • Inzage Ten slotte heeft de gemeente Zoetermeer de intentie om de GBA-applicatie Probev van Procura van een raadpleegfunctie voor woningbouwcorporaties te voorzien. Verder wil zij mogelijk de milieuapplicatie StraBIS van De Straat gaan ontsluiten via de Midoffice Suite ten behoev van de ontsluiting van milieugegevens naar makelaars. Ook hiervoor is een mogelijke oplossing met bijbehorend kostenplaatje gewenst. Producten Daaropvolgend wil de gemeente Zoetermeer de resterende producten van de top-34 uit het Programma Andere Overheid gaan implementeren. In verband met reeds plaatsgevonden hebbende bestuurlijke besluitvorming wil de gemeente dat in het kader van de Initiële implementatie minimaal het maken van een (op de persoon toegesneden) aanvraag voor een Commercieel vertrouwelijk

118


reisdocument en rijbewijs worden gerealiseerd. Binnen de gemeente loopt nog een discussie over de vraag of ook de WMO in het kader van de Initiële implementatie betrokken moet worden. Ook op deze mogelijkheid dient te worden ingegaan.


119


8.8

Infrastructuur

Infra Hardware Databases

Database servers

Alphen a/d Rijn Delft x86 en RS6000 x86 en RISC, Itanium Oracle 9i en 10g Oracle 10g

Ede X86 en HP-UX

IBM AIX

IBM AIX

HP-UX

(evt Linux)

(enkele DB’s met MS SQL Server) MS IIS MS IIS 5 (2000), MS IIS 6 (2003) (evt Apache)

(enkele DB’s met MS SQL Server) MS IIS

MS Windows Server 2003, HP-UX

MS Windows Server 2000

MS IIS

Apache

Applicatie servers

MS Windows Server 2003

(evt MS IIS of Oracle AS) MS Windows Server 2003

OS (desktops)

MS Windows 2000

Web servers

Oracle 9i

Nieuwegein 1

Oracle 8.1.7.4, Oracle 9.2.0.6 (wordt 10g R2) HP-UX (11.11)

MS Windows Server 2000, MS Windows (evt Linux) Server 2003, HP-UX MS Windows XP MS Windows XP MS Windows 2000 SP4

Zoetermeer X86 en HP-UX Oracle 9i en 10g

HP-UX

MS Windows 2000

(wordt XP SP2)

1

Nieuwegein heeft een voorkeur voor bepaalde typen hardware: x86 (Intel, AMD) en RISC, Itanium in de volgende combinaties: - Oracle: RISC, Itanium (Linux, HP-UX) - Server: x86 (Intel, AMD), MS Windows 2003 - Client: x86 (Intel), Windows XP SP2


120


8.9

Gemeentelijke applicaties (top-7)

Producten 1 Uittreksel

Alphen a/d Rijn Delft Centric PIV4all Centric PIV4all

2 Verhuizing Centric PIV4all

3 Grofvuil 4 Afspraken

5 Lichte bouwverg. 6 Melding

7a Bezwaarschrift (algemeen)

7b Bezwaarschrift (WOZ)

Centric PIV4all

MS Access

Meurs Software ARIS Via aanbesteding Bavak

Ede GetronicsPinkRoccade Cipers GetronicsPinkRoccade Cipers Geen Bavak

(als ‘generieke applicatie’) Centric BWT4all Centric BWT4all WAVE Via aanbesteding Meurs Software ARIS (als ‘generieke applicatie’) Circle Software Hummingbird DocMan

Nieuwegein Centric PIV4all

Zoetermeer Procura ProBev

Centric PIV4all

Procura ProBev

Meurs Software ARIS Bavak (incl Q-calendar)

Meurs Software ARIS Bavak

Centric BWT4all Centric BWT4all

Binnenkort vervangen door Prevent

BeheerVisie MeldDesk

BeheerVisie MeldDesk

Circle Software DocMan



(eventueel DMS (eventueel DMS (eventueel DMS (eventueel DMS (eventueel DMS via aanbesteding) via aanbesteding) via aanbesteding) via aanbesteding) via aanbesteding) Gouw Taxatie Centric GHS4all Centric GHS4all Centric HIS4all Centric GHS4all i.c.m. DOC4all


121


8.10 Applicaties (meerwerk) Applicaties Frontoffice

Alphen a/d Rijn Delft Ede Nieuwegein Zoetermeer Via aanbesteding Via aanbesteding Via aanbesteding Via aanbesteding Seneca E-loket Suite (eventueel via aanbesteding) Geen

PerfectView

Geen

Geen

Geen

(eventueel via aanbesteding) Circle Software Document management DocMan 2

(eventueel via aanbesteding) Hummingbird

(eventueel via aanbesteding) Circle Software DocMan

(eventueel via aanbesteding) Circle Software DocMan

(eventueel via aanbesteding) Circle Software DocMan 3

(eventueel via aanbesteding) Product/dien Seneca stencatalogus (eventueel via aanbesteding) ArcGIS GeoFlexiWeb informatie

(eventueel via aanbesteding) Green Valley

(eventueel via (eventueel via aanbesteding) aanbesteding) Via aanbesteding Nog niet bekend

Relatiebeheer

Datadistributie

Geen

(eventueel via aanbesteding) Segment (OPUS)

(project loopt) ArcGIS, ArcIMS, ArcSDE (ESRI Suite) Oracle Spatial

Vicrea

Geen

GetronicsPinkRoccade

(project loopt) Seneca SmartSite Green Valley Applify Content Discovery Server management

FlexiWeb, FlexiMap (incl. PINPOINT) UDS, ArcExplorer, UrbiData MetaData Manager Oracle Spatial Geen

Geodan MapXtreme 3.01 MapInfo Professional 7.5 GeoKey 3.2 en GeoSet, NedGraphics ISIS Oracle Spatial Centric DDS4all

Nog niet bekend

Segment SIMsite

(project loopt)

2 3

Met scanning / imaging van Océ. Momenteel is een pilot gaande met FileNet als DMS; mogelijk wordt dit de gemeentebrede DMS toepassing.


122


8.11 Applicaties (overig) Applicaties Alphen a/d Rijn Delft MS Office 2003 MS Office 2000 Kantoorautomatisering

Ede MS Office XP

Nieuwegein MS Office 2000

Zoetermeer MS Office 2000

Browser

MS IE 6

MS IE 6

MS IE 6

(wordt 2003) MS IE 6

MS IE 6

Groupware

Client: MS Outlook

Client: MS Outlook 2000


Client: MS Outlook XP


Server: MS Exchange 2003 MS Active Directory Cognos Impromptu, Business Objects

Server: MS Exchange 2003 MS Active Directory Cognos Powerplay en Impromptu, ReportNet Decade PION

Server: MS Exchange 2003 MS Active Directory Cognos Powerplay en Impromptu

Server: MS Exchange 2003 MS Active Directory Cognos Powerplay en Impromptu

CODA Raet Beaufort

Centric FIS4all Raet Beaufort

Server: MS Exchange 2003 MS Active Directory Cognos Powerplay en Impromptu, ReportNet Centric FIS4all Raet Beaufort

Identity management Managementinformatie

Financieel Personeel

CODA Raet Beaufort


123


8.12 Initiële implementatie: producten Ten behoeve van de Initiële implementatie zijn zeven gemeentelijke producten geselecteerd: •

Aanvragen GBA-uittreksel

•

Aanvragen binnengemeentelijke verhuizing

•

Aanvragen inzameling grofvuil

•

Afspraak maken

•

Aanvragen lichte bouwvergunning (via Digitaal Bouwloket)

•

Indienen melding openbaar gebied

•

Indienen generiek bezwaarschrift (inclusief WOZ)

In de volgende paragrafen wordt per product een indicatie gegeven van de inrichting daarvan. Per product dient onder meer aandacht te worden besteed aan het elektronische formulier, de inrichting van het gegevens- en zakenmagazijn, de communicatie met alle relevante fronten backoffice applicaties en andere systemen en de inrichting van statussen. Het inrichten van de elektronische formulieren betreft niet alleen de inhoud en de lay-out, maar ook de intelligentie van de formulieren, alsmede validaties (logica) prefill en dergelijke, inclusief de bijbehorende inrichting van het gegevens- en zakenmagazijn. De gemeenten in het Consortium zullen de komende tijd trachten de voornoemde aspecten onderling, voor zover mogelijk, te harmoniseren. De geschetste inrichting van de betreffende producten in deze bijlage is dan ook niet de uiteindelijke beoogde inrichting voor de Initiële implementatie, maar slechts een indicatie daarvan. Bij de daadwerkelijke implementatie zal met de desbetreffende gemeente(n) nader overleg plaatsvinden over de exacte inrichting van de betreffende producten. De verschillende gemeenten in het Consortium hebben echter wel de intentie om deze inrichting, inclusief de bijbehorende processen, gegevens en de validatie daarvan zoveel mogelijk op dezelfde wijze in te richten, zij het dus niet noodzakelijkerwijs zoals hier beschreven. In algemene zin geldt dat de gemeenten in het Consortium liefst zoveel mogelijk validaties ‘aan de voorkant’ willen doen plaatsvinden, dus tijdens de websessie in het elektronische formulier. Aldus kan men ervoor zorgen dat de verstrekte informatie zo ‘schoon’ mogelijk door de gemeente wordt ontvangen. Het betreft hierbij niet alleen eenvoudige validaties op datatypen (bijvoorbeeld of een telefoonnummer wel uit tien cijfers bestaat en dergelijke), maar ook meer complexe validaties (zowel tussen formuliervelden onderling als tegen het gegevensmagazijn). Dit kan bijvoorbeeld betrekking hebben op het matchen van een adres met een postcode (indien deze niet reeds middels prefill op het formulier zijn ingevuld), maar ook van de gezinssamenstelling en –relaties bij opgegeven meeverhuizende personen. De koppeling met de desbetreffende backoffice applicaties maakt als zodanig onderdeel uit van de inrichting van de Initiële implementatie. Bij koppelingen met het backoffice wordt onderscheid gemaakt tussen synchronisatiekoppelingen (voor synchronisatie van gegevens uit een backoffice applicatie met het gegevensmagazijn), transactiekoppelingen (voor het wegschrijven van gegevens in een backoffice applicatie) en statuskoppelingen (voor het teruggeven van de status van zaken zoals aanvragen, meldingen en dergelijke vanuit een Commercieel vertrouwelijk

124


backoffice applicatie naar het zakenmagazijn). De gemeenten in het Consortium hebben de uitdrukkelijke intentie om voor de producten uit de Initiële implementatie naast synchronisatieen statuskoppelingen indien van toepassing ook transactiekoppelingen te realiseren. Volgens het fasemodel elektronische dienstverlening (zie figuur 9) heeft dergelijke transactie integratie betrekking op fase 3. Overigens lenen niet alle gemeentelijke producten zich daadwerkelijk voor elektronische levering (fase 4). Fase Publicatie Fase 0 Papieren formulier Fase 1 Printformulier (PDF / Word) Fase 2 E-formulier

Intake Handmatig (papier) Handmatig (papier) Elektronisch

Fase 3 E-formulier

Elektronisch

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

Fase 4 E-formulier

Elektronisch

Elektronisch

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

Figuur 9: fasemodel elektronische dienstverlening De gewenste transactiekoppelingen zijn koppelingen op applicatieniveau, bij voorkeur op basis van webservices, waarbij de op formulieren ingevulde gegevens volledig automatisch, dus zonder tussenkomst van een medewerker, in de betreffende backoffice applicaties worden ingevoerd met inachtneming van de applicatielogica (business rules of valdaties) van die betreffende backoffice applicatie. Inschrijvers hebben een zware inspanningsverplichting om zulks in overleg met de leveranciers van de betreffende backoffice applicaties te realiseren, waarbij de gemeenten verenigd in het Consortium en EGEM hen desgewenst en voor zover nodig kunnen bijstaan, bijvoorbeeld voor het uitoefenen van druk op de leverancier(s) van de betreffende backoffice applicatie(s). Op basis van een globale procesbeschrijving van de betreffende producten (het betreft hier wederom nadrukkelijk een indicatie) in de volgende paragrafen van deze bijlage zijn per product ook bepaalde consequenties verwoord, bijvoorbeeld voor de inrichting van het gegevensmagazijn, al dan niet verplichte authenticatie (DigiD) en de mogelijkheid tot het bijvoegen van bijlagen bij het formulier. PDC = product/dienstencatalogus GM = gegevensmagazijn DMS = Document Management Systeem GEO = geografische gegevens • Aanvragen GBA-uittreksel -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: ja GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit GBA GEO: Bijlagen: evt (bewijsstukken waarom men in aanmerking komt voor gratis verstrekking) Betalen: ja Overige: documentsjabloon (het uittreksel waarop de gegevens worden ingevuld)


125


• Aanvragen binnengemeentelijke verhuizing -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: ja GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) GM: relaties (partner/ ouders/ verzorgers/ kinderen) uit GBA GM: adresgegevens uit (basis)adressenregistratie GM: bestemming verblijfsobject uit (basis)gebouwenregistratie GEO: nee Bijlagen: eventueel Betalen: eventueel Overige: documenten (huurcontract en dergelijke)

• Aanvragen inzameling grofvuil -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: eventueel GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill (indien DigiD) of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit (basis)adressenregistratie GEO: eventueel (bijvoorbeeld aanklikken ophaallocatie) Bijlagen: nee Betalen: nee Overige: ophaalrooster grofvuil

• Afspraak maken -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: eventueel GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill (indien DigiD) of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit (basis)adressenregistratie GEO: nee Bijlagen: eventueel Betalen: nee Overige: balierooster

• Aanvragen lichte bouwvergunning (via Digitaal Bouwloket) -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: ja GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit (basis)adressenregistratie GEO: eventueel (bijvoorbeeld aanklikken locatie) Bijlagen: eventueel Betalen: eventueel Overige: nvt


126


• Indienen melding openbaar gebied -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: eventueel GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill (indien DigiD) of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit (basis)adressenregistratie GEO: eventueel (bijvoorbeeld aanklikken locatie) Bijlagen: eventueel Betalen: nee Overige: naar klantprofiel (E-mail + telefoonnummer ten behoeve van terugmelding)

• Indienen generiek bezwaarschrift (inclusief WOZ) -

PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden DigiD: ja GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) GM: adresgegevens uit (basis)adressenregistratie GM: WOZ-gegevens GEO: eventueel Bijlagen: eventueel (bijvoorbeeld aanklikken locatie) Betalen: nee Overige:


127


8.12.1 Aanvragen GBA-uittreksel Onderstaande beschrijving is een ‘generiek’ voorbeeld, ter indicatie van het betreffende proces. Het proces ‘aanvragen GBA-uittreksel’ kan bijvoorbeeld ook betaling omvatten.

Starten website

Aanbieden productencatalogus

Selecteren Uittreksel GBA

DigiD Foutmelding Nee Invullen en opsturen authenticatiegege vens

Ontvangen authenticatie gegevens Ja

Geldig?

Versturen anummer

Scherm 1 Identificerende Gegevens

Ophalen adresgegevens

postcode tabel

Versturen gegevens

Scherm 2 Gegevens UIttreksel

Gegevens correct?

Scherm 3 Controleren gegevens

Ja Verzenden en afsluiten

Figuur 10: procesbeschrijving aanvragen GBA-uittreksel4

4

Procesbeschrijving afkomstig van EGEM.


128


8.12.2 Aanvragen binnengemeentelijke verhuizing

Tonen productencatalogus

Starten website

Selecteren Doorgeven Verhuizing DigiD Foutmelding Nee Invullen en opsturen authenticatiegege vens

Ontvangen authenticatie gegevens Ja

Geldig?

Versturen anummer Scherm 1 Identificerende Gegevens

Ophalen adresgegevens Scherm 2 Gegevens Verhuizing

Wijze bewoning nieuwe adres

postcode tabel

Versturen gegevens

Inwonend

Scherm 3 Gegevens inwoning

Verhuizen mensen mee? Ja hoofdbewoner

Scherm 4 Gegevens medeverhuizers

Verhuizen kinderen mee?

Ja

Scherm 5 Gegevens kinderen

Ja

Scherm 6 Gegevens partner

Nee

Nee

Verhuist partner mee? Nee

Gegevens correct?

Verzenden en afsluiten

Scherm 7 Gegevens oude woning


Figuur 11: procesbeschrijving aanvragen binnengemeentelijke verhuizing5

5



129


8.12.3 Aanvragen inzameling grofvuil

Figuur 12: schermafdruk PDC-beschrijving inzameling grofvuil6

Figuur 13: schermafdruk aanvraagformulier inzameling grofvuil (1/6)7

6 7

Schermafdruk afkomstig van de gemeente Delft. Schermafdruk afkomstig van de gemeente Delft.


130




8 9



131




10 11



132



Figuur 19: schermafdruk reactieformulier inzameling grofvuil13

12 13



133


8.12.4 Afspraak maken

Figuur 20: procesbeschrijving afspraak maken (1+2 / 7)14

14

Schermafdruk afkomstig van de gemeente Hilversum.


134



15



135



16



136


Figuur 23: procesbeschrijving afspraak maken (7 / 7)17

17



137


8.12.5 Aanvragen lichte bouwvergunning (via Digitaal Bouwloket) Voor het aanvragen van een lichte bouwvergunning zal gebruik gemaakt worden van het desbetreffende aanvraagformulier dat beschikbaar is via het zogeheten Digitaal Bouwloket.

Figuur 24: procesbeschrijving aanvragen lichte bouwvergunning18

18

Procesbeschrijving afkomstig van de gemeente Delft.


138


8.12.6 Indienen melding openbaar gebied Dienstenaanbieder (eFormulier gemeente)

Klant

Centrale Voorzieningen

Productaanbieder (gemeente)

Tonen productencatalogus

Starten website

Selecteren Melding Leefomgeving

Scherm 1 Identificerende Gegevens

Ophalen adresgegevens

postcode tabel

Versturen gegevens

Scherm 2 Soort Melding en Omschrijving

Scherm 3 Locatie

Veroorzaker bekend? Ja

Scherm 4 Gegevens Veroorzaker

Nee

N.V.T.

Scherm 5 Toevoegen Bijlagen

Gegevens correct?

Verzenden en afsluiten


Verzenden gegevens

Figuur 25: procesbeschrijving indienen melding openbaar gebied19

19



139


8.12.7 Indienen generiek bezwaarschrift (inclusief WOZ)

Figuur 26: procesbeschrijving indienen generiek bezwaarschrift (inclusief WOZ)20

20

Procesbeschrijving afkomstig van gemeente de Delft.


140


8.13 Beschrijving Proof of Concept Inleiding Een Proof of Concept (PoC) maakt mogelijk deel uit van de Midoffice Suite aanbesteding (zie ook paragraaf 2.5.4). Tijdens de PoC willen de gemeenten, behalve een succesvolle installatie, graag zien dat de Inschrijvers een aantal minimale functionaliteiten realiseren. De teamleden die betrokken zijn bij de PoC, dienen tevens in gelijkwaardige hoedanigheid betrokken te zijn bij de Initiële implementatie. Hieronder is aangegeven wat het resultaat van de PoC moet zijn, uitgesplitst naar de verplicht te offreren elementen en de overige elementen. Indien bekend is welke gemeenten een PoC willen uitvoeren zal een beschrijving van de PoC infrastructuur omgeving naar de betreffende Inschrijvers worden gestuurd. Bijlage 8.8 bevat een beschrijving van de huidige infrastructuren. De PoC infrastructuur zal hiervan afgeleid zijn. Indien er sprake is van een PoC zal er één centrale PoC gehouden worden, dus niet één per gemeente. Naast het installeren van de proefopstelling dient de Inschrijver tijdens de PoC één of meer presentaties te geven voor belanghebbenden binnen het Consortium. Ook zal het geoffreerde team door het beoordelingsteam van het Consortium worden geïnterviewd. Resultaat PoC Midoffice Suite Hieronder staan per onderdeel van de Midoffice Suite de gewenste projectresultaten van de Proof of Concept. •

Basisvoorwaarden De Midoffice Suite zal op de voor de PoC beschikbaar gestelde hardware op de PoC hosting locatie geïnstalleerd en volledig werkend zijn. De (eventueel) noodzakelijke ondersteunende applicatie(s) zoals webserver, applicatieserver en andere applicaties moeten geïnstalleerd zijn en draaien. Instellingen, configuraties ten behoeve van de integratie tussen de verschillende onderdelen dienen te zijn gemaakt. Indien een ASPoplossing wordt aangeboden, zal een ASP testomgeving actief zijn, vergelijkbaar met een productieomgeving. - Tenminste een minimale autorisatiestructuur (rechten en rollen) voor medewerkers en klanten is aanwezig, inclusief DigiD authenticatie voor de klanten. Er is een testset van tenminste vijf FO/KCC-medewerkers, vijfburgers en vijf bedrijven ingericht. Het Consortium verzorgt de NAW-gegevens en een DigiD-testaccount voor elke burger. - De beheersomgeving voor webintake, vraaggeleiding, workflow en dergelijke is gerealiseerd. -

•

Frontoffice Een klant kan via vraaggeleiding naar het juiste formulier worden geleid. Klanten kunnen inloggen via DigiD, waarna zoveel mogelijk relevante bekende informatie vooringevuld wordt. - Na insturen van een ingevuld formulier kan een zaak worden gecreëerd en afgehandeld. Alle elementen van deze keten kunnen worden beheerd en aangepast. -


141


Wat betreft validaties dient er tenminste singlefield validatie op datatype te zijn geïmplementeerd, maar liever multifield validatie, zoals een check of postcode en straatnaam overeenkomen en bij voorkeur ook validatie met het gegevensmagazijn en/of zakenmagazijn. - Elektronisch betalen: een klant kan tenminste een vast bedrag betalen. Dit kan bijvoorbeeld middels een testaccount bij Ogone. -

•

Midoffice -

-

-

•

De functionaliteit ‘Mijn loket’ is beschikbaar, alwaar een testburger kan inloggen en tenminste de statussen van de persoonlijke aanvragen zien. Een gegevensmagazijn is gerealiseerd en volledig beschreven. In ieder geval wordt hieruit informatie gehaald ten behoeve van prefill. Een basisinrichting van het zakenmagazijn is gerealiseerd. Naar het zakenmagazijn wordt in ieder geval geschreven: informatie n.a.v. ingevulde formulieren, wijzigingen via de beheersinterface van een FO/KCC-medewerker en statusupdates van KCC- en/of backoffice processen. Bij klantcontacten kan een FO/KCC-medewerker contactinformatie bijhouden en eerdere klantcontacten opzoeken. Rudimentaire A2A en A2P workflow (inclusief status) is ingericht rondom afhandeling van een zaak en koppeling met een externe applicatie. Er is een document repository ingericht, waarin enige testdocumenten zitten. Er bestaat de mogelijkheid om afhankelijk van de rechten van de FO/KCC-medewerker documenten in te zien, te bewerken, metadata te wijzigen, te verwijderen en dergelijke. Postregistratie van zowel inkomende stukken (inclusief scannen) en uitgaande post (inclusief E-mail) is mogelijk. Documentinvoer: er is functionaliteit aanwezig om documenten toe te voegen Metadatering aan documenten en dossiers is mogelijk. Dossiervorming, inclusief een koppeling met het zakenmagazijn is mogelijk. De functionaliteit voor het genereren van zowel standaard managementrapportages als zelfgedefinieerde managementrapportages is beschikbaar. Er is een beheersomgeving voor het maken en wijzigen van menselijke workflow aanwezig. Generieke applicatie: melding openbaar gebied

-

•

Een generieke applicatie waarmee een melding openbaar gebied afgehandeld kan worden is gerealiseerd. Product X

Product X, een van de top-7 producten, dient volledig te worden ingericht. Hieronder wordt verstaan: Productformulieren inclusief intelligentie, validaties en prefill zijn beschikbaar. Koppelingen met het gegevens- (synchronisatie) en zakenmagazijn (statusupdate) zijn gerealiseerd. - Proactieve en reactieve statusupdates kunnen automatisch naar de aanvrager worden verstuurd. - FO/KCC-medewerkers kunnen statussen inzien en wijzigen in het zakenmagazijn. - Transactie-, synchronisatieen statuskoppeling met backoffice applicatie gerealiseerd. -


142


Aanvragen kunnen worden doorgesluisd naar backoffice applicatie en statusinformatie over een specifieke zaak kan worden teruggestuurd naar of opgevraagd uit deze applicatie. - Voor FO/KCC- en DIV-medewerkers bestaat de mogelijkheid om documenten (zoals TIFF- of Word bestanden) toe te voegen aan een zaak(dossier) en op te slaan in het DMS. -

Voor de Proof of Concept gelden de algemene voorwaarden in bijlage 8.14. Iedere Inschrijver dient zich akkoord te verklaren met de gestelde voorwaarden.


143


8.14 Algemene voorwaarden Proof of Concept Artikel 1: Begrippen 1.1

Producten: de op basis van deze voorwaarden en de sub 3.1 bedoelde overeenkomst door Leverancier ter beschikking te stellen programmatuur en/of apparatuur.

1.2

Opdrachtgever: het Consortium.

1.3

Leverancier: de partij die de Producten voor het uitvoeren van een Testprocedure aan Opdrachtgever op basis van deze voorwaarden ter beschikking stelt.

1.4

Programma van Eisen: het geheel van functionele en technische specificaties waar de Producten aan dienen te voldoen. Het toepasselijke Programma van Eisen wordt nader in de Testopdracht geduid.

1.5

Testprocedure: de test waarmee kan worden aangetoond dat de Producten in samenhang met de infrastructuur zoals geschetst in het betreffende Programma van Eisen aan de door Leverancier opgegeven specificaties voldoen.

1.6

Testopdracht: de schriftelijke opdracht sub 3.1 bedoeld waarmee Opdrachtgever verzoekt de Producten voor het uitvoeren van een Testprocedure ter beschikking te stellen.

Artikel 2: Toepasselijkheid 2.1

Alle overeenkomsten met betrekking tot het ter beschikking stellen van Producten voor Testprocedures zijn onderworpen aan de navolgende voorwaarden. Aanvullende of afwijkende voorwaarden en bedingen gelden slechts indien en voor zover die door Opdrachtgever uitdrukkelijk schriftelijk zijn aanvaard.

2.2

Algemene voorwaarden van Leverancier c.q. enige derde zijn niet van toepassing op de sub 2.1 genoemde overeenkomsten.

Artikel 3: Overeenkomst 3.1

Een overeenkomst met betrekking tot het ter beschikking stellen van Producten voor Testprocedures komt tot stand (i) nadat Leverancier een Testopdracht van Opdrachtgever schriftelijk bevestigt, of (ii), bij het ontbreken van een Testopdracht, nadat de ontvangst van het Product door een daartoe bevoegde functionaris van Opdrachtgever is bevestigd.

3.2

De Producten worden door Leverancier om niet ter beschikking gesteld aan Opdrachtgever, tenzij anders overeengekomen in de Testopdracht.

3.3

De Producten mogen door Opdrachtgever alleen worden gebruikt voor de Testprocedure(s).

3.4

Een overeenkomst eindigt: (i) met volbrenging van de Testprocedure, of (ii) door opzegging door Opdrachtgever, of (iii) na afloop van de in de overeenkomst bepaalde periode.


144


3.5

Na beëindiging van de overeenkomst zal Opdrachtgever de Producten aan Leverancier terug geven, tenzij partijen anders overeenkomen.

Artikel 4: Aflevering en tijdelijke licentie 4.1

Leverancier zal de Producten op de overeengekomen datum franco op het door Opdrachtgever aangegeven afleveradres afleveren.

4.2

Opdrachtgever zal de afgeleverde Producten controleren op onder meer beschadiging, maat, hoeveelheid en, indien van toepassing, gewicht. Een dergelijke controle zal binnen twee dagen na levering plaatsvinden, waarna het risico voor verlies en beschadiging overgaat naar Opdrachtgever. Opdrachtgever is aansprakelijk voor de goede en doelmatige bewaring en beveiliging van de Producten.

4.3

Opdrachtgever zal Leverancier onverwijld in kennis stellen van schade of verlies van de Producten.

4.4

Indien de afgeleverde Producten (mede) uit programmatuur bestaan zal Leverancier een niet exclusief en niet overdraagbaar gebruiksrecht aan Opdrachtgever verlenen ten behoeve en voor de termijn van de Testprocedure. Leverancier zal tevens de benodigde toegangskey(s) verstrekken en, indien overeengekomen, een testopstelling verzorgen.

4.5

Enkel Opdrachtgever, inclusief door Opdrachtgever ingeschakelde consultants, heeft (hebben) het recht de programmatuur te gebruiken en daartoe toegang te verkrijgen. De programmatuur mag enkel toegankelijk worden gemaakt middels en worden gebruikt op de systemen die in het kader van de Testprocedure zijn aangewezen door Opdrachtgever.

Artikel 5: Installatie 5.1

Leverancier verklaart zich bereid om, indien Opdrachtgever daartoe verzoekt, de programmatuur en/of apparatuur op locatie bij Opdrachtgever te installeren c.q. Opdrachtgever te ondersteunen bij de installatie.

5.2

Tenzij uitdrukkelijk anders overeengekomen, zal de sub 5.1 bedoelde dienstverlening kosteloos worden uitgevoerd door Leverancier.

Artikel 6: (Intellectueel) eigendom 6.1

Het (intellectueel) eigendom van de programmatuur en/of apparatuur blijft bij Leverancier berusten.

Artikel 7: Testprocedure 7.1

Partijen zullen in onderling overleg procedures vaststellen ten aanzien van de werkwijze met betrekking tot het uitvoeren van de Testprocedure.

7.2

De Testprocedure zal door Opdrachtgever worden vastgesteld. Op verzoek van Opdrachtgever zal Leverancier kosteloos, tenzij anders overeengekomen, ondersteuning verlenen bij het vaststellen op welke wijze de Testprocedure zal worden uitgevoerd.


145


7.3

De Testprocedure zal binnen een redelijke termijn worden uitgevoerd. Direct nadat deze heeft plaatsgevonden, zal Opdrachtgever een verslag opstellen en dit aan Leverancier doen toekomen. In dit verslag zal worden vastgelegd welke gebreken de programmatuur en/of apparatuur vertoont en voorts of de bevindingen als positief of negatief door Opdrachtgever zijn ervaren.

7.4

Indien de Testprocedure is afgerond zal de overeenkomst overeenkomstig het sub 3.4 en 3.5 bepaalde worden beëindigd.

Artikel 8: Overige bepalingen 8.1

Het bepaalde uit titel 13, boek 7A, van het Burgerlijk Wetboek is van toepassing op deze voorwaarden en zal op de sub 3.1 bedoelde overeenkomst van toepassing zijn.

8.2

Leverancier kan op basis van het tot stand komen van de sub 3.1. bedoelde overeenkomst c.q. op basis van de sub 7.3 bedoelde bevindingen geen enkel recht ontlenen aan het tot stand komen van enige koop- en/of licentieovereenkomst c.q. de gunning van enige opdracht door Opdrachtgever.

8.3

Opdrachtgever is te allen tijde bevoegd de overeenkomst zonder enige opzeggingstermijn te beëindigen, waarna het bepaalde sub 3.5 van toepassing is.

8.4

Wijzigingen op de overeenkomst kunnen slechts schriftelijk worden overeengekomen.

8.5

Alle geschillen in verband met de overeenkomst worden beslecht door de bevoegde rechter in het arrondissement Den Haag.

8.6

Op de overeenkomst zal Nederlands recht van toepassing zijn.


146


8.15 Controlelijst eisen In de controlelijst eisen (tabel 11) dient de Inschrijver in de kolom ‘Akkoord (ja/nee)’ aan te geven of hij voldoet aan de betreffende eis. De kolom ‘Behandeld (ja/nee)’ dient ter controle of de betreffende eis is beantwoord. In de kolom ‘Toelichting’ kan een korte toelichting worden opgenomen. Nota bene -

Een toelichting op een eis mag, overeenkomstig het gestelde in paraaf 3.4.1, geen voorbehoud impliceren.

-

De geformuleerde eisen gelden als absoluut criterium, dat wil zeggen dat als aan één of meerdere eisen niet wordt voldaan, de Offerte terzijde gelegd wordt.

-

Bij verschillen tussen de controlelijst en de individuele beantwoording van de eisen is deze laatste leidend. Nr.

Akkoord (ja/nee)

Behandeld (ja/nee)

Toelichting

E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13 E14 E15 E16 E17 E18 E19 E20 E21 E22 E23 E24 E25 E26 E27 E28 E29 Commercieel vertrouwelijk

147


Nr.

Akkoord (ja/nee)

Behandeld (ja/nee)

Toelichting

E30 E31 E32 E33 E34 E35 E36 E37 E38 E39 E40 Tabel 11: controlelijst eisen


148


8.16 Controlelijst vragen De vragen in dit Bestek hebben een verschillende weging. De vragen aangeduid met een ‘ster’ (*) wegen in de beoordeling twee keer zo zwaar als de andere vragen. U wordt verzocht bij iedere vraag aan te geven en uitvoerig te documenteren (hiermee wordt tevens bedoeld verwijzen naar meegeleverde documentatie en dus niet naar URL’s): -

In hoeverre de aangeboden applicatie(s) de genoemde aspecten ‘out-of-the-box’ ondersteunen, met vermelding van eventueel noodzakelijke add-on modules en hun versienummers.

-

In hoeverre de aangeboden applicatie(s) de genoemde aspecten door middel van ontwikkeltools / maatwerk ondersteunen.

-

In welke applicatie de genoemde aspecten zitten (indien u meerdere applicaties aanbiedt voor verschillende aspecten).

Alle antwoorden kunnen middels een Proof of Concept (zie ook paragraaf 2.5.4) geverifieerd worden. Ook als u één applicatie aanbiedt voor meerdere aspecten, dient u toch alle vragen afzonderlijk te beantwoorden. Tabel 12 bevat de controlelijst vragen. •

De kolom ‘behandeld (ja/nee)’ is een controlemiddel voor de Inschrijver om te bepalen of alle vragen zijn beantwoord. In de kolom ‘Toelichting’ kan een korte toelichting worden opgenomen:

•

Onder ‘maatwerk (ja/nee)’ dient (indien van toepassing) vermeld te worden of er bij het betreffende antwoord sprake is van maatwerk.

•

Onder ‘add-ons (ja/nee)’ dient (indien van toepassing) vermeld te worden of er bij het betreffende antwoord sprake is van add-ons.

•

Onder ‘toelichting’ kan een eventuele overige toelichting worden opgenomen.

Wanneer bij de beantwoording van een vraag sprake is van add-ons en/of maatwerk bovenop de standaardapplicatie(s), dan wordt ervan uitgegaan dat de kosten hiervan gespecificeerd zijn in de prijsopgave (zie hoofdstuk 6). Nr.

Behandeld (ja/nee)

Maatwerk (ja/nee)

Add-ons (ja/nee)

Toelichting

V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 Commercieel vertrouwelijk

149


Nr.

Behandeld (ja/nee)

Maatwerk (ja/nee)

Add-ons (ja/nee)

Toelichting

V11 V12 V13 V14 V15 V16 V17 V18 V19 V20 V21 V22 V23 V24 V25 V26 V27 V28 V29 V30 V31 V32 V33 V34 V35 V36 V37 V38 V39 V40 V41 V42 V43 V44 V45 V46 V47 V48 V49 V50 V51 V52 V53 V54 V55 V56 V57 Commercieel vertrouwelijk

150


Nr.

Behandeld (ja/nee)

Maatwerk (ja/nee)

Add-ons (ja/nee)

Toelichting

V58 V59 V60 V61 V62 V63 V64 V65 V66 V67 V68 V69 V70 V71 V72 V73 V74 V75 V76 V77 V78 V79 V80 V81 V82 V83 V84 V85 V86 V87 V88 V89 V90 V91 V92 V93 V94 V95 V96 V97 V98 V99 V100 Tabel 12: controlelijst vragen


151


8.17 Eigen verklaring Naam Inschrijver: Adres: Plaats: Telefoonnummer: Faxnummer:

………………………… ………………………… ………………………… ………………………… …………………………

Inschrijver verklaart dat niet één van de onderstaande omstandigheden ten aanzien van Inschrijver van toepassing is: -

Hij in staat van faillissement of van liquidatie verkeert, zijn werkzaamheden zijn gestaakt, dat voor hem een surseance van betaling of een akkoord geldt of in een vergelijkbare toestand verkeert ingevolge een soortgelijke procedure die voorkomt in de op hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie;

-

Hij zijn faillissement of liquidatie heeft aangevraagd, of tegen hem een procedure van surséance van betaling of akkoord dan wel een andere soortgelijke procedure die voorkomt in de op hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie, aanhangig is gemaakt;

-

Tegen hem een rechtelijke uitspraak met kracht van gewijsde volgens de hem van toepassing zijnde wet- of regelgeving van een lidstaat van de Europese Unie is gedaan, waarbij een delict is vastgesteld dat in strijd is met zijn beroepsgedragsregels;

-

Hij in de uitoefening van zijn beroep een ernstige fout heeft begaan, vastgesteld op elke grond die het Consortium aannemelijk kan maken;

-

Hij niet aan zijn verplichtingen heeft voldaan ten aanzien van de betaling van de sociale verzekeringsbijdragen overeenkomstig de wettelijke bepalingen van het land waar hij gevestigd is of van Nederland;

-

Hij niet aan zijn verplichtingen heeft voldaan ten aanzien van de betaling van zijn belastingen overeenkomstig de wettelijke bepalingen van het land waar hij gevestigd is of van Nederland;

-

Hij zich in ernstige mate schuldig heeft gemaakt aan valse verklaringen bij het verstrekken van de inlichtingen die overeenkomstig hoofdstuk 4 kunnen worden verlangd, of die inlichtingen niet heeft verstrekt.

-

Hij bij een gerechtelijk vonnis, dat kracht van gewijsde heeft, wegens deelneming aan een criminele organisatie, omkoping, fraude of het witwassen van geld, is veroordeeld.

Inschrijver verklaart, dat hij deze verklaring naar waarheid heeft ondertekend. Plaats: Datum: Naam: Functie:

………………………… ………………………… ………………………… …………………………

Handtekening:

…………………………


152


8.18 Conceptovereenkomst Apart bijgevoegd Zie apart bijgevoegd document Conceptovereenkomst Midoffice Suite.pdf.


153


8.19 Conformiteitenlijst conceptovereenkomst Deze conformiteitenlijst biedt de mogelijkheid om per artikel van de conceptovereenkomst (zie bijlage 8.18) aan te geven of het tekstvoorstel akkoord is. Daar waar de Inschrijver wenst af te wijken van de voorgelegde bepaling(en) geeft hij dit aan door het invullen van een ‘V’ in de kolom ‘Niet Akkoord’. In dat geval dient Inschrijver op het formulier een tekstvoorstel te doen. Als Inschrijver ‘Niet akkoord’ is en geen nieuw tekstvoorstel doet dan wordt er van uitgegaan dat Inschrijver niet instemt met het artikel. Indien de Inschrijver van mening is dat in de voorgelegde overeenkomst zaken ontbreken, kan dit onderaan het formulier aangeven worden met een tekstvoorstel. Geef daarbij aan na welk artikelnummer het betreffende tekstvoorstel dient te worden opgenomen. NB: het Consortium is geenszins verplicht de voorgestelde tekstvoorstellen over te nemen. Overeenkomst levering en implementatie van fronten midoffice Artikel- Wel Niet Tekstvoorstel nummer Akkoord Akkoord Considerans 1 Begrippen 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 2 Onderwerp 2.1 2.2 2.3 2.4 3 Vertegenwoordiging, projectleiding, (voortgangs)rapportage en overleg 3.1 3.2 Commercieel vertrouwelijk

154


3.3 3.4 3.5 3.6 3.7 4 Aanvang werkzaamheden; duur van de Overeenkomst 4.1 4.2 5 Wijzigen van de Overeenkomst 5.1 5.2 5.3 6 Oplevering en Acceptatie 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 7 Garantie 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.2 7.3 7.4 7.5 7.6 8 Licentie 8.1 8.2 8.3 8.4 8.5 8.6 9 Onderhoud 9.1 9.2 10 Service Level Management 10.1 10.2 10.3 11 Aansprakelijkheid 11.1


155


11.1.1 11.1.2 11.2 11.3 11.4 11.5 11.6 12 Prijzen 12.1 12.2 12.3 12.4 12.5 13 Betaling 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 14 Intellectuele (eigendoms)rechten 14.1 14.2 14.3 14.4 15 Geheimhouding en beveiliging 15.1 15.2 15.3 16 Verzekering 16.1 17 Ondersteuning 17.1 18 Documentatie 18.1 18.2 18.2.1 18.2.2 18.2.3 18.2.4 18.2.5 18.3 18.4 18.5 19 Niet toerekenbare tekortkoming (overmacht) 19.1 19.2


156


20 Ontbinding 20.1 20.1.1 20.1.2 20.1.3 20.2 21 Overdracht rechten en verplichtingen; onderaanneming 21.1 21.2 22 Geschillen en toepasselijk recht 22.1 22.2 22.3 23 Algemeen 23.1 23.2 23.3


157


8.20 Verklarende woordenlijst -

A2A: application-to-application of tussen applicaties onderling (zie applicatie workflow).

-

A2P: application-to-person of tussen applicaties en mensen (zie menselijke workflow).

-

Adapters: adapters zijn stukjes software die de informatieoverdracht regelen tussen de broker en de daarop aangesloten applicaties en systemen.

-

Applicatie workflow: workflow waarbij uitsluitend interactie tussen applicaties onderling plaatsvindt genoemd (in tegenstelling tot menselijke workflow).

-

Authenticatie: authenticatie behelst het proces waarbij wordt vastgesteld of iemand een bepaalde identiteit terecht claimt.

-

Backoffice: het backoffice vormt het hart van een organisatie waar zich, onzichtbaar voor de buitenwereld, de primaire (gegevensverwerkende) processen afspelen.

-

Backoffice applicatie: een backoffice applicatie levert gegevensverwerkende en -opslag functionaliteit.

-

Basisgegevens: basisgegevens zijn gegevens die voor meer dan één proces of product(groep) in een organisatie van belang zijn. Als zodanig komen zij in meer dan één productgroep GFO voor.

-

Basisregistratie: een basisregistratie is een registratie die uitsluitend basisgegevens bevat (personen, bedrijven en instellingen, gebouwen, adressen, percelen en topografie).

-

Broker: een broker, ook wel berichtencentrale of message- c.q. integratiebroker genoemd, zorgt ervoor dat de juiste berichten in het juiste formaat op het juiste moment via de juiste route bij de juiste applicaties terechtkomen. Als zodanig vormt de broker het hart van het midoffice.

-

Business Process Management (BPM): Business Process Management is het routeren van elektronische berichten en orkestreren van werkstromen tussen applicaties onderling.

-

Content management systeem (CMS): een (web) Content Management Systeem biedt functionaliteit om content te ‘begeleiden’ vanaf het moment dat deze wordt gecreëerd in een redactieomgeving tot het moment waarop deze in de juiste context (structuur en vormgeving) wordt gepresenteerd in een publicatieomgeving.

-

Customer Relationship Management (CRM): Customer Relationship Management is het registreren en combineren van (klant)gegevens uit verschillende (proces)applicaties voor het open uitbouwen van klantprofielen en -relaties.

-

Customer Relationship Management (CRM) systeem: een Customer Relationship Management systeem of applicatie biedt functionaliteit voor Customer Relationship Management.

-

Document Management Systeem (DMS): een document management systeem levert bepaalde functionaliteit voor het invoeren, opslaan, archiveren en ontsluiten van documenten.


158


Documentair Structuur Plan (DSP): een plan waarin de wijze is vastgelegd waarop de toegankelijkheid van archiefbescheiden is georganiseerd en de wijze waarop deze zijn ingedeeld en gerangschikt.

-

Formulier: een formulier is een voor een gegeven procedure, al dan niet in oplage aangemaakt invulmodel, ingericht om gegevens uniform, systematisch en volledig vast te leggen (invullen en aanvullen), te lezen, te bewerken, te transporteren, te reproduceren, op te bergen en op te zoeken. In de context van dit Bestek wordt hiermee, tenzij uitdrukkelijk anders vermeld, steeds een elektronisch formulier bedoeld dat ingevuld kan worden in een browser (webformulier).

-

First party (1P): first party heeft betrekking op de geoffreerde applicatie(s) of functionaliteiten die worden meegeleverd met de geoffreerde applicatie(s). Als zodanig heeft ‘first party’ per definitie betrekking op applicaties en functionaliteiten die geleverd worden door de Inschrijver die ze offreert.

-

Frontoffice: het frontoffice is de presentatielaag van een organisatie naar de buitenwereld toe; alle interactie met die buitenwereld speelt zich in het frontoffice af.

-

Gegevensmagazijn: Een gegevensmagazijn dient voor opslag (cache) van gegevens uit de backoffice applicaties. Gegevens worden naar de centrale database in de DMZ gekopieerd, alwaar ze 24/7 read-only beschikbaar zijn.

-

Gemeentelijk Functioneel Ontwerp (GFO): er zijn ongeveer 25 GFO’s voor verschillende beleidsterreinen. Aanvankelijk waren GFO’s vooral gegevenswoordenboeken, maar momenteel zijn het meer objectmodellen met gedefinieerde eigenschappen van de objecten die in het model voorkomen. Bij die eigenschappen horen weer begrippen en begripsdefinities.

-

Gestructureerde gegevens: gestructureerde gegevens betreffen alle gegevens die als databaserecord kunnen worden opgeslagen.

-

Identificatie: identificatie is het proces waarbij de identiteit van een persoon wordt vastgesteld.

-

Kanalen: kanalen zijn de verschillende manieren waarop in het frontoffice met de ‘klant’ wordt geïnteracteerd, zoals telefoon, balie, website, E-mail en post.

-

Koppelvlak: een koppelvlak beschrijft de elektronische communicatie tussen twee (of meer) applicaties.

-

Menselijke workflow: workflow waarbij interactie plaatsvindt tussen een applicatie aan de ene kant en een mens aan de andere kant. Menselijke workflow onderscheidt zich van applicatie workflow door het gebruik van werkvoorraden, taakbakjes en dergelijke.

-

Midoffice: het midoffice omvat een verzameling functionaliteiten die de processen en bijbehorende applicaties en gegevens in het frontoffice en het backoffice met elkaar verbindt.

-

Ongestructureerde gegevens: ongestructureerde gegevens betreffen alle gegevens die niet als databaserecord kunnen worden opgeslagen, zoals documenten, geografische kaarten, tekeningen en dergelijke.


159


Open source software: open source software heeft twee kenmerken: de broncode is vrij beschikbaar en in het licentiemodel is het intellectueel eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig geregeld dat de licentienemer deze mag inzien, gebruiken, verbeteren, aanvullen en distribueren.

-

Portal: een portal biedt functionaliteit waarmee relevante informatie en toepassingen kunnen worden aangeboden aan (groepen van) eindgebruikers op een gepersonaliseerde manier.

-

Procesapplicatie: een procesapplicatie is een backoffice applicatie die dient ter ondersteuning van één specifiek proces.

-

Product: in het kader van dit Bestek wordt met ‘product’ een gemeentelijk(e) product of dienst bedoeld, zoals een lichte bouwvergunning, binnengemeentelijke verhuizing en dergelijke.

-

Product/dienstencatalogus (PDC): een product/dienstencatalogus biedt functionaliteit voor het beschrijven en ontsluiten van (groepen van) producten en diensten over het web.

-

ReMANO: ReMANO is het acroniem voor Records Management Applicaties voor de Nederlandse Overheid en behelst bepaalde softwarespecificaties voor records management.

-

Screenscraping: bij screenscraping vindt applicatie-integratie plaats op presentatieniveau; via een hiertoe gecreëerde ‘virtuele’ gebruiker wordt data in de applicatie geschreven of eruit gelezen.

-

Semantiek: semantiek verwijst naar betekenis (bijvoorbeeld van een elektronisch bericht).

-

Statuskoppelingen: een koppeling voor het teruggeven van de status van zaken zoals aanvragen en meldingen vanuit een backoffice applicatie naar het zakenmagazijn.

-

Synchronisatiekoppelingen: een koppeling voor synchronisatie van gegevens uit een backoffice applicatie met het gegevensmagazijn.

-

Syntax: syntax verwijst naar vorm (bijvoorbeeld van een elektronisch bericht).

-

Third party (3P): third party heeft betrekking op andere dan de geoffreerde applicatie(s) of functionaliteiten die niet worden meegeleverd met de geoffreerde applicatie(s). Als zodanig heeft ‘third party’ per definitie betrekking op applicaties en functionaliteiten die niet geleverd worden door de Inschrijver maar door een derde partij. In het algemeen heeft de term ‘third party’ betrekking op applicaties of functionaliteiten die reeds aanwezig zijn.

-

Transactie: een transactie wordt gezien als reeks processtappen die samen een logische eenheid vormen en niet los van elkaar kunnen worden uitgevoerd; een transactie vindt hetzij helemaal, hetzij helemaal niet plaats.

-

Transactiekoppelingen: een koppeling voor het wegschrijven van gegevens in een backoffice applicatie.

-

Vraagtrechter: een vraagtrechter is een opeenvolgende reeks gesloten vragen (meestal ja/nee) door middel waarvan bijvoorbeeld de gewenste product(groep) in een product/dienstencatalogus kan worden gelokaliseerd.


160


Vraagpatroon: een vraagpatroon behelst alle (zoek)methoden om via interactie het gewenste product te lokaliseren in een product/dienstencatalogus (zoals via een vraagtrechter, menu, zoekterm, lijst of op levensgebeurtenis).

-

Webintake: web intake behelst de aanvraag een product middels een webformulier, meestal via een elektronisch loket.

-

Webintake systeem: ook wel formulierenserver. Een web intake systeem biedt functionaliteit voor het ontwikkelen/beheren van webformulieren, het publiceren en vervolgens doen invullen ervan op een elektronisch loket, alsmede het verwerken van de ingevulde webformulieren.

-

Webformulier: zie formulier.

-

Wizard presentatie: de wizard presentatie is een publicatiemethode voor elektronische formulieren waarbij het formulier stap voor stap doorlopen wordt; de verschillende onderdelen (pagina’s, onderwerpblokken) worden één voor één aan de gebruiker getoond.

-

Workflow management (WfM): een workflow management systeem biedt functionaliteit voor het aansturen van werkstromen tussen applicaties en mensen.

-

Xforms: Xforms is een relatief nieuwe formulierenstandaard, een platformonafhankelijke XML-variant die een markup language voor formulieren biedt.

-

Zaak: een zaak bestaat altijd uit een samenhangende hoeveelheid werk die op verzoek van iemand wordt uitgevoerd en leidt over het algemeen tot een nauwkeurig gedefinieerd resultaat; voor gemeenten zal dit resultaat veelal een beschikking zijn.

-

Zaakdossier: een zaakdossier bevat voor één specifieke zaak zowel de gestructureerde gegevens als de ongestructureerde gegevens; een zaakdossier heeft voor een zaak zowel betrekking op de inhoud als op het proces.

-

Zaakitem: een zaakitem betreft een specifiek zaak (bijvoorbeeld een specifieke aanvraag voor een parkeervergunning).

-

Zaaktype: een zaaktype is een bepaald soort zaak (bijvoorbeeld een kapvergunning).


161

Europese aanbesteding Midoffice Suite

Recommend Documents