Europese aanbesteding Midoffice Suite

Transcriptie

1 Europese aanbesteding Midoffice Suite Barendrecht, Barneveld, Maastricht, het Openbaar Lichaam NOFA, Utrecht, Veghel en Venlo onder aanvoering van EGEM en begeleid door M&I/Argitek Europese aanbesteding Status: Definitief Versie: 1.0 Datum: 28 maart 2007

2 INHOUDSOPGAVE Leeswijzer Algemeen Inleiding Achtergrond en doelstelling Begrippen Procedures Algemeen Bestek Vertrouwelijkheid Intellectueel eigendom Voorbehoud Relatie met het zogeheten ANDEZ Bestek Onjuistheden Offertefase Schriftelijke vragen Prebid meeting Sluitingsdatum Offertes Openen Offertes Beschikbaarheid Inschrijvers Kwalitatieve selectie Beoordelingsfase Te offreren onderdelen Programma van Eisen Verduidelijkingsessies Gunningcriteria en weging Bepaling Top-n Proof of Concept (PoC) Globale planning Gunning Initiële implementatie Algemene voorwaarden aan de Offerte Contactpersonen Taal Managementsamenvatting...24 Europese aanbesteding , 28 maart

3 3.4 Eisen en vragen Toelichting begrippen Vorm beantwoording Controlelijst eisen Controlelijst vragen Geldigheidsduur Aanlevering Voorbehouden Referenties Criteria voor kwalitatieve selectie Combinaties en onderaanneming Eisen aan Inschrijvers Verklaringen Gesteldheid Financiële en economische draagkracht Technische bekwaamheid Programma van Eisen Inleiding Achtergrond Frontoffice Klantcontactcentrum Broker Datadistributie Eisen Midoffice Suite Vragen Midoffice Suite: frontoffice Webintake Vraaggeleiding en product-dienstencatalogus Authenticatie en personalisatie Zoeken Web Content Management Geo-informatie presentatie Elektronische betalen Overig Vragen Midoffice Suite: klantcontactcentrum Gegevensmagazijn Zakenmagazijn Workflow management Relatiebeheer...66 Europese aanbesteding , 28 maart

4 5.4.5 Generieke applicatie Document management Overig Vragen Midoffice Suite: broker en technische architectuur Broker Datadistributie Adapters Technische architectuur Overig Vragen Midoffice Suite: gebruiksgemak en beheer Gebruiksgemak Beheer Managementrapportage Integratie Eisen en vragen Initiële implementatie Inleiding Eisen implementatie Vragen implementatie Financiën Juridische voorwaarden Bijlagen Prijssjabloon Europese aanbesteding Midoffice Suite Algemene toelichting prijssjabloon Applicaties en componenten Software Prijzen maatwerksoftware Initiële Implementatie Training en documentatie Verplicht meer- / minderwerk Optioneel meerwerk Tarieven & Opslagen Beheer Huidige infrastructuur Gemeentelijke applicaties (top-7) Aanbesteding, meer- en minderwerk Kentallen gemeenten Beschrijving Proof of Concept Europese aanbesteding , 28 maart

5 8.7 Initiële implementatie: producten Top-34 producten Controlelijst eisen Controlelijst vragen en functionaliteiten Eigen verklaring Conceptovereenkomst Algemene voorwaarden Proof of Concept Voorbeeld Service Niveau Overeenkomst Conformiteitenlijst conceptovereenkomst Voorbeeld procesafhandeling Aanvraag evenementenvergunning Configuratie zaaktype verplichte koppelingen per status/resultaat Behandeling zaak Voorbeeldformulier evenementenvergunning Voorbeeldschermen en processen Top-7 producten Aanvragen afschrift GBA Verhuizing (binnen- én intergemeentelijk) Indienen melding openbaar gebied Indienen generiek bezwaarschrift Aanvragen evenementenvergunning Aanvragen gecombineerde BKS-vergunning Intern proces: in- en uitdiensttreding Gemeentespecifieke bijlage Barendrecht Gemeentespecifieke bijlage Barneveld Gemeentespecifieke bijlage Maastricht Gemeentespecifieke bijlage NOFA Gemeentespecifieke bijlage Utrecht Gemeentespecifieke bijlage Veghel Gemeentespecifieke bijlage Venlo Verklarende woordenlijst Europese aanbesteding , 28 maart

6 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. Europese aanbesteding , 28 maart

7 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. 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 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 1, hoewel dit Bestek een enigszins afwijkende terminologie hanteert. Daarnaast is voor dit Bestek ook gekeken naar de zogeheten Nederlandse Overheid Referentie Architectuur (NORA 2 ), alsook naar de beoordelingscriteria van het laboratoriumonderzoek van adviesbureau M&I/Argitek 3, dat deze aanbesteding begeleidt. Het onderhavige Bestek is samengesteld op basis van en voor wat betreft de opzet grotendeels gelijk aan het bestek van Europese aanbesteding van de zogeheten ANDEZ -gemeenten (Alphen aan den Rijn, Delft, Ede, Nieuwegein en Zoetermeer). 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 CMS, een product-dienstencatalogus (PDC) en dergelijke e-overheid.nl/atlas/referentiearchitectuur en het boek Het Midoffice (ISBN ) Europese aanbesteding , 28 maart

8 Klantcontactcentrum (KCC) Het klantcontactcentrum (KCC) omvat, naast een gegevens- en een zakenmagazijn, ook 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-functie bevat zogeheten Business Process Management (BPM) functionaliteit, alsmede zogeheten adapters. Bij deze brokerlaag behoren tevens datadistributiemogelijkheden. 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 front- en het backoffice beheersbaar te houden. Aldus vormt het midoffice als het ware een generiek (ont)koppelvlak waarop de verschillende front- en backoffices kunnen worden aangesloten. Zeven aanbestedende diensten, zeven percelen en EGEM De samenwerkende gemeenten Barendrecht, Barneveld, Maastricht, Utrecht, Veghel en Venlo treden individueel op als aanbestedende dienst in het kader van de onderhavige Europese aanbesteding. Tevens maakt het Openbaar Lichaam Noordoost Friese Aanpak (NOFA) deel uit van de samenwerkende gemeenten en ook zij treedt op als aanbestedende dienst. Alle deelnemende gemeenten en het Openbaar Lichaam worden in het vervolg van dit Bestek met Gemeente(n) aangeduid, de samenwerking als ANDEZ-2. Alle gemeenten hebben EGEM een volmacht gegeven om namens hen op te treden als penvoerder en regisseur bij deze Europese aanbesteding. M&I/Argitek is adviseur van EGEM en van de gemeenten. Iedere Gemeente zal echter zelf een gunningbesluit nemen en individueel tot contractering overgaan, op basis van de bij dit Bestek gevoegde modelovereenkomst. Dit betekent dat er per Gemeente aan een Inschrijver wordt gegund en dat er zeven maal aan maximaal zeven verschillende Inschrijvers kan worden gegund. De onderhavige Europese aanbesteding is in die zin opgebouwd uit zeven verschillende percelen (perceel Barendrecht, perceel Barneveld, etc.). De samenwerkende gemeenten besteden ieder 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, product- en procesbeschrijvingen en datamodellen voor de inrichting van gegevens- en zakenmagazijn en dergelijke kan (laten) ontwikkelen en uitwisselen. Opzet aanbesteding en de te contracteren opdrachten Deze aanbesteding vormt door de opzet in feite een vraagbundeling van de samenwerkende gemeenten. De eisen en wensen van de samenwerkende gemeenten inzake een Midoffice Suite komen grotendeels overeen. Bij iedere Gemeente is er echter sprake van een specifieke achtergrond met andere accenten. In dit Bestek komt dit tot uitdrukking doordat, in aanvulling op Europese aanbesteding , 28 maart

9 het generieke deel, voor elke Gemeente een specifieke bijlage is opgenomen (zie bijlagen 8.18 t/m 8.24) met eventuele aanvullingen. Daarnaast bevatten de bijlagen 8.2 t/m 8.4 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. Op basis van deze aanbesteding wordt per Gemeente aan een Inschrijver de opdracht gegund om de applicatie(s) te leveren die in de gewenste functionaliteiten van de Midoffice Suite voorzien en die bovendien als Initiële implementatiepartner de Initiële implementatie uitvoert. Daartoe wordt per Gemeente een overeenkomst met een Inschrijver aangegaan die voorziet in de contractering van de volgende opdracht: de licentiering van de aangeboden Midoffice Suite; de projectmatige Initiële implementatie; de levering van onderhoud. Iedere overeenkomst heeft een looptijd van drie jaar met tweemaal de mogelijkheid tot verlenging met één jaar. De uiteindelijke selecties zouden in de tweede helft van 2007 zijn beslag moeten krijgen. Elke deelnemende Gemeente heeft de optie om ook na de Initiële implementatie met de door hem geselecteerde Inschrijver door te gaan met het aanvullend implementeren van de zgn. Top- 34 gemeentelijke producten zoals genoemd door het Programma Andere Overheid en opgesomd in paragraaf 8.8 onder de voorwaarden van de Offerte. 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). Ondanks de hiervoor beschreven vermelding dat deze aanbesteding uit zeven percelen is opgebouwd, is het niet toegestaan op slechts één of enkele percelen in te schrijven. U bent verplicht om op alle zeven percelen tegelijk in te schrijven. De beoordeling geschiedt echter, zoals hiervoor is aangegeven, uitdrukkelijk per perceel waarbij steeds een beoordelingsteam van een relevante Gemeente is betrokken (met het oog op de beoordeling van de gemeentespecifieke vragen). Dit houdt echter tevens in dat u er niet vanuit mag gaan dat gunning van één perceel automatisch gunning van alle percelen met zich brengt. Gunningtraject Na het beoordelen van de Offertes ontstaat voor iedere Gemeente een top-3 van Inschrijvers, welke worden samengevoegd tot één Top-n van Inschrijvers. Deze Top-n wordt 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.6) zal worden gewaardeerd. Teamleden die bij de Proof of Concept betrokken zijn, dienen ook bij eventuele uiteindelijke implementatie(s) betrokken te zijn, in een gelijkwaardige rol. Het Europese aanbesteding , 28 maart

10 geoffreerde team dient het resultaat van de Proof of Concept te demonstreren en verduidelijken. Eén en ander wordt uitgebreid toegelicht in paragraaf Elke Gemeente gunt vervolgens aan een Inschrijver die op basis van zijn beoordeling de hoogste totaalscore voor specifiek die Gemeente heeft behaald. Overeenkomstig artikel 54 van het BAO vindt per perceel gunning plaats aan de Inschrijver met de vanuit het oogpunt van de Gemeenten economisch meest voordelige aanbieding. 1.3 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.25 een verklarende woordenlijst. ANDEZ-2 Zie Gemeente. Bestek Dit document inclusief alle genoemde bijlagen. Combinatie De ondernemingen die gezamenlijk één Offerte bij de Gemeenten aanbieden en waarbij geen sprake is van Onderaanneming. Iedere deelnemer in een Combinatie is verplicht de Overeenkomst te ondertekenen en is jegens de Gemeente als Contractant verantwoordelijk voor nakoming van alle uit de aanbesteding voortvloeiende verplichtingen c.q. de Overeenkomst, ongeacht of de verplichtingen door hemzelf of door een andere deelnemer aan de Combinatie worden uitgevoerd. Contractant De Inschrijver aan wie de opdracht voor een perceel op basis van deze Europese aanbesteding wordt gegund. 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 Contractant die ze heeft geoffreerd. Gemeente Waar in dit bestek over Gemeente wordt gesproken, wordt bedoeld de gezamenlijk aanbestedende gemeenten, te weten: - Gemeente Barendrecht (ca inwoners) - Gemeente Barneveld (ca inwoners) - Het Openbaar Lichaam Noordoost Friese Aanpak (samen ca inwoners) - Gemeente Maastricht (ca inwoners) - Gemeente Utrecht (ca inwoners) - Gemeente Veghel (ca inwoners) Europese aanbesteding , 28 maart

11 - Gemeente Venlo (ca inwoners) Deze gemeenten vertegenwoordigen gezamenlijk niet alleen ruim inwoners, maar kunnen ook model staan voor de meeste middelgrote gemeenten. Het Openbaar Lichaam Noordoost Friese Aanpak bestaat uit de gemeenten Achtkarspelen, Dantumadeel, Dongeradeel en Kollumerland c.a. en wordt in dit bestek aangeduid als NOFA. Zie ook Aanbestedende diensten en EGEM in paragraaf 1.2. Initiële implementatie De installatie en basisimplementatie van de Midoffice Suite, alsmede de inrichting van de eerste zeven Top-7 producten (zie bijlage 8.7). 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. Inschrijver De onderneming die zelfstandig of als lid van een Combinatie op basis van de in het Bestek gestelde voorwaarden een Offerte uitbrengt. 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 - (Web) content management (CMS) - Webintake - Vraaggeleiding en zoeken - Product-dienstencatalogus (PDC) - Authenticatie - Personalisatie - Elektronisch betalen - Geo-informatie (presentatie) - Klantcontactcentrum - Gegevensmagazijn - Zakenmagazijn - Generieke applicatie - Workflow management (WfM) - Document management (DMS) - Relatiebeheer (CRM) Europese aanbesteding , 28 maart

12 - Broker - Broker - Adapters - Datadistributie Max-price Maximale oftewel not to exceed prijs, op basis van nacalculatie. Dit betekent dat de verleende diensten worden geoffreerd op basis van nacalculatie, waarbij het Inschrijver niet is toegestaan de geoffreerde Max-price (prijsplafond) te overschrijden. Zie ook de bijlage 8.1, Prijssjabloon. Meerwerk Er zijn twee vormen van meerwerk: verplicht meerwerk en optioneel meerwerk. Waar meerwerk als optioneel is aangeduid, is de Inschrijver niet verplicht vragen hieromtrent te beantwoorden en / of om de gevraagde functionaliteiten te offreren. Antwoorden op vragen m.b.t. optioneel meerwerk tellen niet mee bij bepaling van de p-, de q- of de f-score zoals beschreven in paragraaf en tellen dus ook niet bij bepaling van de Top-1 per Gemeente, de Top-3 per Gemeente of de Top-n. Het is aan de Gemeente om bij gunning het eventuele optionele meerwerk af te nemen, afhankelijk van het aanbod en de antwoorden bij de desbetreffende vragen. Verplicht meerwerk betreft koppeling met reeds bij Gemeenten aanwezige Midoffice applicaties. Optioneel meerwerk betreft aanvullende functionaliteiten of diensten zoals bedoeld in de conceptovereenkomst. Nota van Inlichtingen De nota die aan alle Inschrijvers wordt verzonden en waarbij alle gestelde vragen geanonimiseerd worden beantwoord en de eventuele wijzigingen op het Bestek worden beschreven. De Nota van Inlichtingen maakt daarmee deel uit van het Bestek. Offerte Alle documenten die de Inschrijver aanbiedt ter beantwoording van het gestelde in dit Bestek, inclusief eventuele Addenda die na vragen ter verduidelijking later worden gecommuniceerd. Onderaannemer De onderneming die niet als zelfstandige Inschrijver aanbiedt en die geen formele partij bij de te sluiten Overeenkomst zal zijn. De Onderaannemer gaat rechten en verplichtingen aan jegens de Inschrijver c.q. Contractant terwijl de Inschrijver c.q. Contractant jegens de Gemeente verantwoordelijk is voor nakoming van de uit de aanbesteding voortvloeiende verplichtingen c.q. de Overeenkomst. Overeenkomst De Overeenkomst bevat de bepalingen die van toepassing zijn op de uitvoering van de opdracht. In bijlage 8.12 is de Overeenkomst opgenomen. Zie ook E38 op bladzijde 105. Europese aanbesteding , 28 maart

13 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 Contractant maar door een derde partij. In het algemeen heeft de term third party betrekking op applicaties, functionaliteiten, componenten en dergelijke die reeds aanwezig zijn. Top-3 Er is een Top-3 per Gemeente. De Top-3 bestaat uit de (bij voldoende Inschrijvers) drie Inschrijvers met de hoogste f-score voor de desbetreffende Gemeente. Zie ook paragraaf en paragraaf Top-7 De 7 gemeentelijke producten, zoals gedefinieerd in paragraaf 8.7. Top-34 De 34 gemeentelijke producten, zoals genoemd in paragraaf 8.8. Top-n De Top-n bestaat uit alle Inschrijvers die in de Top-3 van een of meer Gemeenten staan. Zie ook paragraaf en paragraaf Europese aanbesteding , 28 maart

14 2 PROCEDURES 2.1 Algemeen Voor de onderhavige openbare aanbesteding wordt het 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: M&I/Argitek treedt voor vragen rondom de aanbesteding als contactpersoon op: - Contactpersoon: M. (Michael) Roovers - mroovers@argitek.nl NB: het indienen van de Offertes geschiedt via EGEM (zie paragraaf 2.3.3). 2.2 Bestek Vertrouwelijkheid De Gemeenten, EGEM, M&I/Argitek 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 vertrouwelijkheid zal ook worden bewaard wanneer de Offerte niet tot de totstandkoming van een overeenkomst zal leiden 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 Voorbehoud Uit het Bestek vloeien geen verplichtingen voort voor de Gemeenten, anders dan de verplichting zich aan de aanbestedingsprocedure te houden. De Gemeenten behouden zich het recht voor om vanwege politiek/bestuurlijke, financiële en / of inhoudelijke redenen hun participatie in de aanbestedingsprocedure stop te zetten, geheel of gedeeltelijk op te schorten dan wel te beëindigen. Inschrijvers hebben geen recht op vergoeding van enigerlei kosten en / of geleden of te lijden schade gemaakt in het kader van deze aanbestedingsprocedure (met uitzondering van de PoC). Europese aanbesteding , 28 maart

15 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 per Gemeente niet anders plaats kunnen vinden dan na een bevoegd besluit ter zake door de desbetreffende Gemeente. Na de gunning start de implementatie met de installatie en de basisimplementatie (zie paragraaf 5.7), gevolgd door een acceptatietest van deze werkzaamheden. Indien er geen acceptatie van de resultaten van de test kan plaatsvinden door de Gemeente dan is dit een reden de overeenkomst te ontbinden. Indien de overeenkomst op grond hiervan wordt ontbonden kan de Gemeente alsnog onder gelijke voorwaarden als in deze alinea is beschreven een overeenkomst sluiten met de als tweede geëindigde Inschrijver Relatie met het zogeheten ANDEZ Bestek Dit Bestek is samengesteld op basis van en grotendeels gelijk aan het bestek van Europese aanbesteding van de zogeheten ANDEZ -gemeenten (Alphen aan den Rijn, Delft, Ede, Nieuwegein en Zoetermeer), verder te noemen ANDEZ-1. De onderhavige samenwerking van Gemeenten wordt aangeduid als ANDEZ Onjuistheden Dit Bestek met alle bijbehorende bijlagen is met zorg samengesteld. Mocht u desondanks tegenstrijdigheden en / of onvolkomenheden tegenkomen, dan verzoeken wij u M&I/Argitek hier onverwijld schriftelijk van op de hoogte te stellen via het in paragraaf 2.1 genoemde adres. 2.3 Offertefase Schriftelijke vragen Inschrijvers kunnen uitsluitend schriftelijk vragen stellen met betrekking tot het Bestek, tot uiterlijk 15 mei Vragen kunnen uitsluitend per , onder vermelding van Vragen Midoffice Suite ANDEZ-2, ref , worden ingediend via het in paragraaf 2.1 genoemde adres. Alle vragen worden schriftelijk beantwoord. De vragen en antwoorden zullen geanonimiseerd en gelijktijdig aan alle Inschrijvers per 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, vraag en / of paragraaf. 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 Europese aanbesteding , 28 maart

16 Bestek door de Gemeenten, zullen aan alle Inschrijvers per door middel van een Nota van Inlichtingen kenbaar worden gemaakt Prebid meeting Indien aantal en aard van de ingediende vragen daartoe aanleiding geven, zal er op 7 mei 2007 van 11:00 uur tot 12: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 door middel van de Nota van Inlichtingen aan iedere Inschrijver worden toegestuurd. Ook als er geen prebid meeting wordt georganiseerd, zullen de antwoorden op de gestelde vragen schriftelijk en geanonimiseerd door middel van de Nota van Inlichtingen aan iedere Inschrijver worden verzonden 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 21 mei 2007 om 12:00 uur op onderstaand adres ontvangen zijn. Indiening geschiedt bij voorkeur op 21 mei 2007 tussen 11:00 en 12:00 uur op de volgende locatie: EGEM - Contactpersoon: M. (Mark) van den Broek - Adres: Wilhelmina van Pruisenweg AN, Den Haag (Nederland) Indien indiening eerder of anderszins gewenst is, kan dit eveneens via bovenstaande (post- c.q. afgifte)adres. Bij ontvangst van de Offerte zal een ontvangstbewijs worden afgegeven. NB: voor toegang 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 of telefax 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. Europese aanbesteding , 28 maart

17 - Offertes die na de sluitingsdatum en -tijd 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 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 Beschikbaarheid Inschrijvers Van de Inschrijvers wordt verwacht dat zij tijdens de beoordelingsfase van 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 per perceel gunning plaats aan de Inschrijver met de vanuit het oogpunt van de Gemeenten economisch meest voordelige aanbieding. Conform paragraaf 1.2 geldt dat iedere Gemeente individueel een opdracht gunt aan de voor die Gemeente economisch meest voordelige aanbieding 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. Niet alle Gemeenten die in deze Aanbesteding deelnemen zullen de volledige Midoffice Suite afnemen. 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 en in paragraaf 8.1. Europese aanbesteding , 28 maart

18 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) 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. - Vragen die zijn aangeduid met hekje (#) betreffen optioneel meerwerk en zijn van puur informatieve aard. Deze wegen niet mee t.b.v. het bepalen van de Top-3 of de Top-n. Beantwoording hiervan is derhalve niet verplicht Verduidelijkingsessies Indien een Gemeente een onvoldoende beeld van de Inschrijver en haar aanbod heeft gekregen op basis van de Offertes, worden mogelijk een of enkele verduidelijkingsessies georganiseerd, waar in separate sessies alle aspecten van het aanbod aan de orde kunnen worden gesteld aan de Inschrijver. Deze sessies zullen twee maal gedaan worden: één maal voor bepaling van de Top-n en één maal per Gemeente voor gunning. De inhoud van deze vragen zal voor zover mogelijk vooraf worden verschaft. Daarnaast zal in de week van 27 tot en met 31 augustus de PoC van Top-n Inschrijvers worden beoordeeld, zie ook paragraaf en paragraaf Gunningcriteria en weging Nadat de Offertes waarvan de Inschrijvers niet voldoen aan de eisen voor kwalitatieve selectie van hoofdstuk 4 zijn verwijderd, vindt er in een viertal rondes per perceel 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.2). 2 Daarna worden van de resterende Offertes de antwoorden op de vragen in het Programma van Eisen met dubbele weging, gemarkeerd met een ster (*), op een vijfpuntschaal beoordeeld als Europese aanbesteding , 28 maart

19 slecht, matig, voldoende, goed of uitstekend. Offertes dienen in deze tweede ronde voor minimaal 90% van deze vragen voldoende, goed of uitstekend te scoren. Wanneer dat niet het geval is, wordt de Offerte terzijde gelegd. 3 Vragen die zijn aangeduid met hekje (#) betreffen optioneel meerwerk en zijn van puur informatieve aard. Deze worden níet beoordeeld en wegen niet mee t.b.v. het bepalen van de Top-3 of de Top-n. Beantwoording van met een hekje aangeduide vragen is derhalve niet verplicht. 4 Van de resterende Offertes worden alle vragen met enkele weging beoordeeld op een driepuntschaal beoordeeld als zwak, voldoende of sterk. 5 Ten slotte wordt uit de kwaliteitsscore q en de prijs p de totaalscore f bepaald en wordt er per Gemeente een top-3 vastgesteld. Beoordeling van een vraag geschiedt door een team van onafhankelijk van elkaar beoordelende vertegenwoordigers van de Gemeenten, van EGEM en van M&I/Argitek. De score per vraag is het gemiddelde van alle beoordelaars. In een afstemmingsoverleg van het beoordelingsteam worden de extreme scores besproken en nader gemotiveerd en eventueel aangepast. De gemeentespecifieke vragen worden per Gemeente beoordeeld door een team van onafhankelijk van elkaar beoordelende vertegenwoordigers per Gemeente. De score per vraag per Gemeente is het gemiddelde van alle desbetreffende beoordelaars. Bepalen kwaliteitscore q Per groep vragen (zie tabel 2-1) 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. De laagst mogelijke score is nul en de hoogst mogelijke score is honderd (conform de wegingen in tabel 2-1). Er wordt bij beoordeling van de antwoorden op de vragen in dit Bestek een q-waarde berekend per Gemeente. De meeste vragen worden door de Gemeenten als geheel beoordeeld, een aantal vragen zijn gemeentespecifiek. Dit is dan aangegeven in de vraag zelf. Onderdelen met betrekking tot de kwaliteit Weging 1 De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over frontoffice V1 t/m V De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over klantcontactcentrum (inclusief document management) V21 t/m V De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over broker en technische architectuur V46 t/m V De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over gebruiksgemak en beheer V75 t/m V De mate waarin wordt voldaan aan de vragen uit het Programma van Eisen over Initiële implementatie V92 t/m V Totaal 100 Tabel 2-1: onderdelen kwaliteitsscore Europese aanbesteding , 28 maart

20 Bepalen totaalprijs p De totaalprijs p wordt berekend op basis van de licentiekosten (exclusief kosten voor licenties van operating systemen en DBMS en) voor vijf jaar, de kosten voor het onderhoud en de ondersteuning van de software (incl. maatwerk) over vijf jaar, maatwerk, training en gebruikersdocumentatie en driemaal de kosten voor de Max-price geoffreerde Initiële implementatie (incl. koppeling met backoffice applicaties bij dun uitgevoerde producten van de Top-7). Hierbij wordt een door de Gemeenten te maken inschatting van de eventuele extra kosten van beheer, hardware, platformen (operating systemen, databases en dergelijke) over vijf jaar en andere exploitatiekosten op basis van de geleverde specificaties opgeteld. Bepalen totaalscore f Op basis van de totale kwaliteitscore q en de totaalprijs p wordt ten slotte volgens de formule f = q + a 100% (pmin / p) de totaalscore f bepaald, waarbij: - f = totaalscore - q = kwaliteitscore - a = p = totaalprijs - pmin = laagste totaalprijs van alle overgebleven Offertes Onderstaand volgt een voorbeeld van deze score. De Offerte van Inschrijver A krijgt totaal 60% van het maximaal te behalen aantal punten en heeft een aanbod van 900 incl. BTW, waarvan 600 voor de initiële implementatie. Daarbij schatten de Gemeenten de overige kosten (exploitatie en beheer) op 10. De p van inschrijver A wordt dan dus ( ) + 3* = Inschrijver B krijgt in totaal 55% van het maximaal te behalen aantal punten en heeft een aanbod van 700 incl. BTW, waarvan 400 voor de initiële implementatie. Daarbij schatten de Gemeenten de overige kosten (exploitatie en beheer) op 20. De p van inschrijver B wordt dan dus ( ) + 3* = Dat betekent dat pmin = De totaalscores zijn nu: - Voor Inschrijver A: f = 60% * 100% * (1.520/2.200) = 81% - Voor Inschrijver B: f = 55% * 100% * (1.520/1.520) = 85% Inschrijver B heeft de hoogste f-score en zal in dit geval dus de gunning krijgen Bepaling Top-n Op basis van de gemeentespecifieke f-scores wordt per Gemeente een top-3 bepaald. De Top-n wordt gevormd door alle Inschrijvers die in de Top-3 van een Gemeente zijn geëindigd. Alle overige Inschrijvers vallen af en ontvangen hiervan bericht. Europese aanbesteding , 28 maart

21 2.5.6 Proof of Concept (PoC) Vervolgens worden de Inschrijvers uit de Top-n verzocht hun propositie in een proefopstelling te demonstreren. Door middel van de Proof of Concept (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.6 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. Er wordt één centrale PoC gehouden. Per Inschrijver wordt een vergoeding van 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 deelnemende Gemeenten een opdracht gegund wordt. Geoffreerde teamleden die bij de uiteindelijke implementatie(s) betrokken zijn, dienen ook bij een eventuele PoC betrokken te zijn, in een gelijkwaardige rol. Het geoffreerde team dient het resultaat van de Proof of Concept te demonstreren en verduidelijken. Voor de PoC gelden de algemene voorwaarden in bijlage 1.1. Inschrijver dient zich expliciet akkoord te verklaren met de gestelde voorwaarden. Na het uitvoeren van de PoC zal het resultaat per Gemeente worden beoordeeld aan het criterium: de mate waarin wordt voldaan aan het Resultaat PoC Midoffice Suite (zie 8.6). Deze scores worden per Gemeente verwerkt in de definitieve kwaliteitsscore q. Tevens kunnen de prijzen per Gemeente worden verduidelijkt op basis waarvan een definitieve prijsscore p en totaalscore f wordt bepaald, op basis waarvan per Gemeente een definitieve Top-3 zal worden bepaald. Desgewenst (zie ook paragraaf 2.2.3) wordt de opdracht, bij geen bezwaar, gegund aan de Inschrijver met de hoogste totaalscore f, de Top-1 Inschrijver. Voor de berekening van de kwaliteitsscore q en de totaalscore f zie paragraaf Globale planning De globale planning van de het traject is weergegeven in tabel 2-2. Gemeenten kunnen, bij geen bezwaar, vanaf 27 oktober 2007 de definitieve gunning doen. 28 maart 2007 Aankondiging van de aanbesteding in het Publicatieblad van de EU 7 mei 2007 Eventuele prebid meeting 15 mei 2007 Sluiting verzoeken om nadere informatie 21 mei :00 Sluiting inzending; aanvang evaluatie Offertes 29 en 30 mei 2007 Eventuele verduidelijkingsessies 4 juni 2007 Top-3 per Gemeente bekend 5 juni 2007 Verzenden uitnodiging PoC en afschrijven overige Inschrijvers 27 juni 2007 Technische installatie PoC gereed Europese aanbesteding , 28 maart

22 27 t/m 31 augustus e of 4 e week van september 2007 Configuratie gereed, presentatie en demonstraties; evaluatie PoC Eventuele verduidelijkingsessie per Gemeente 12 oktober 2007 (Voornemen tot) Gunning exclusief 15 kalenderdagen bezwaartermijn 2.7 Gunning Tabel 2-2: globale planning Onverkort het hiervoor in paragraaf 2.1 vermelde zal iedere deelnemende Gemeente aan de door hem 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) 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 een te zijner tijd bekend te maken persoon / personen. Aangezien het hier om zeven percelen gaat kunt u maximaal zeven gunnings- of afschrijvingsbrieven ontvangen, van zeven verschillende Gemeenten. Een belanghebbende, die het niet met het gunningbesluit van een Gemeente eens is, kan binnen een termijn van 15 dagen na het voornemen tot gunning daartegen een (civiel) kort geding aanspannen. In het belang van een snelle en goede voortgang, wordt men in dat geval dringend verzocht de betreffende Gemeente tijdig op de hoogte te stellen van het aanwenden van dit rechtsmiddel, bij voorkeur door het opsturen aan de betreffende Gemeente 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 de Gemeenten worden vastgesteld, uitgaande van maximaal 3 gelijktijdige implementaties per Inschrijver op een moment. 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 Europese aanbesteding , 28 maart

23 waarschijnlijkheid dat de Initiële implementaties deels opeenvolgend en deels parallel zullen plaatsvinden. Europese aanbesteding , 28 maart

24 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 - 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 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. - Vragen die zijn aangeduid met hekje (#) betreffen optioneel meerwerk en zijn van puur informatieve aard. Deze wegen niet mee t.b.v. het bepalen van de Top-3 of de Top-n. Beantwoording hiervan is derhalve niet verplicht Toelichting begrippen Eisen en vragen zijn uniek geïdentificeerd en worden als volgt onderscheiden: Europese aanbesteding , 28 maart

25 Eis (E) Aan een eis moet zonder voorbehoud worden voldaan (absoluut criterium). Indien niet wordt voldaan aan een eis wordt de Offerte ongeldig verklaard en zal de Offerte worden uitgesloten van verdere beoordeling. Vraag (V) Met de vragen wordt beoogd uw Offerte af te kunnen zetten tegen concurrerende Offertes (relatief criterium). Inschrijver moet expliciet op elke vraag in gaan en het betreffende antwoord motiveren; het uitsluitend met ja / nee beantwoorden is niet voldoende. Eisen dienen uitsluitend met ja/nee te worden beantwoord en moeten in voorkomend geval worden voorzien van een bewijs dat bij de geformuleerde eis wordt vermeld. 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 een antwoord bij iedere vraag te geven en uitvoerig te documenteren (hiermee wordt tevens bedoeld verwijzen naar meegeleverde documentatie, URL s worden niet geaccepteerd als documentatie omdat de inhoud van de site kan veranderen): - In hoeverre de aangeboden applicatie(s) en/of add-ons de genoemde functionaliteiten out-ofthe-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 add-ons apart te worden beantwoord. Toelichtingen of voorbehouden die op meerdere vragen van toepassing zijn, hoeven niet te worden herhaald. Hier 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 of maatwerk bovenop de standaardapplicatie(s) en/of niet reeds bij de Gemeenten aanwezige applicaties van derden vereist zijn dan wordt ervan uitgegaan dat de kosten hiervan gespecificeerd zijn in de prijsopgave (zie hoofdstuk 6 en bijlage ). Indien blijkt dat dit niet geval is zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van de ontbrekende onderdelen gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfaitbedrag, zoals besproken in paragraaf De Gemeenten zijn 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). Desgewenst mogen niet-commerciële bijlagen, zoals aanvullende documentatie Europese aanbesteding , 28 maart

26 gebruikershandleidingen, whitepapers, etc. waar in beantwoording van de vragen in Hoofdstuk 5 naar wordt verwezen ook alleen elektronisch worden aangeleverd 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.Y) 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. Bij beantwoording van een eis dient expliciet te worden vermeld of de Inschrijver eraan voldoet. (controlelijst hierop aanpassen) Controlelijst eisen In bijlage 8.9 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. Nota bene - De geformuleerde eisen gelden als absoluut criterium, dat wil zeggen dat als aan één of meerdere eisen niet wordt voldaan, de Offerte ongeldig wordt verklaard en terzijde wordt gelegd. - Bij verschillen tussen de controlelijst en de individuele beantwoording van de eisen is deze laatste leidend Controlelijst vragen Inschrijver dient Bijlage 8.10: Controlelijst vragen en functionaliteiten in te vullen (zie ook de toelichting aldaar). In de kolom Maatwerk (ja/nee) dient u aan te geven of er maatwerk nodig is om alle functionaliteit te realiseren die in het antwoord op de betreffende vraag door de Inschrijver wordt genoemd. In de kolom Toelichting kan een korte toelichting worden opgenomen. In de kolom Applicaties, modules. etc. dient u aan te geven welke applicaties (inclusief koppelingen, addons, maatwerksoftware, etc.) of diensten nodig zijn om alle functionaliteit die in het antwoord op de betreffende vraag door de Inschrijver wordt genoemd te realiseren. Met de in deze kolom genoemde applicaties (inclusief koppelingen, add-ons, maatwerksoftware, etc.) en diensten dient alle functionaliteit die in de antwoorden op de vragen door de Inschrijver wordt genoemd te kunnen worden gerealiseerd. Indien blijkt dat dit niet geval is zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van de ontbrekende onderdelen gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfaitbedrag. Europese aanbesteding , 28 maart

27 Nota bene Bij verschillen tussen de controlelijst en de individuele beantwoording van de vragen is deze laatste leidend. 3.5 Geldigheidsduur De Offerte is tenminste geldig tot 1 mei Tot die datum heeft zij het karakter van een onherroepelijk aanbod. 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 Aanbesteding, ref De ingediende exemplaren van de Offerte worden eigendom van de Gemeenten. 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 negen kopieën. Desgewenst mogen niet-commerciële bijlagen, zoals aanvullende documentatie gebruikershandleidingen, whitepapers, etc. waar in beantwoording van de vragen in Hoofdstuk 5 naar wordt verwezen ook alleen elektronisch worden aangeleverd. - 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 (versie 2000, XP of 2003) of als PDF-bestand. - Spreadsheets als Microsoft Excel bestand (versie 2000, XP of 2003). - Presentaties als Microsoft PowerPoint bestand (versie 2000, XP of 2003) of als PDF-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. Europese aanbesteding , 28 maart

28 3.8 Referenties De Gemeenten 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 selectietraject plaats te kunnen hebben. De procedure rond het opgeven van referenties wordt uitgebreid toegelicht in pararaaf Europese aanbesteding , 28 maart

29 4 CRITERIA VOOR KWALITATIEVE SELECTIE In dit hoofdstuk worden de criteria voor kwalitatieve selectie van de Inschrijvers behandeld. 4.1 Combinaties en onderaanneming E1 E2 E3 Eenmaal aanbieden Een onderneming mag slechts éénmaal aanbieden, hetzij zelfstandig of als deelnemer in een Combinatie of als Onderaannemer bij een Inschrijver. De deelnemers in een Combinatie c.q. in een verhouding Onderaannemer Inschrijver zijn ieder ten opzichte van elkaar én ten opzichte van de Gemeente verantwoordelijk voor de nakoming van deze eis. Indien een onderneming meer dan éénmaal aanbiedt worden alle door hem, hetzij zelfstandig of als deelnemer in Combinatie of in een verhouding Onderaannemer - Inschrijver, uitgebrachte Offertes ter zijde gelegd en uitgesloten van beoordeling. In het geval een onderneming meerdere malen aanbiedt worden ook de Offertes van de overige deelnemers in de betreffende Combinaties c.q. in een verhouding Onderaannemer Inschrijver ter zijde gelegd en uitgesloten van beoordeling. Een en ander geldt voor zover E2 niet van toepassing is. Eenmaal als Onderaannemer aanbieden Een onderneming mag slechts éénmaal als Onderaannemer optreden, tenzij de Onderaannemer uitsluitend softwarelicenties en het standaard onderhoud daarop levert. Dit betekent dat, indien een implementatiepartij er voor kiest als Onderaannemer op te treden, hij dit slechts éénmaal kan doen. De Inschrijver is jegens de gunnende Gemeenten verantwoordelijk voor de nakoming van deze eis door de Onderaannemer. Dit betekent dat de Offerte van de Inschrijver ter zijde wordt gelegd en uitgesloten van beoordeling indien blijkt dat de betreffende Onderaannemer bij meerdere Offertes als zodanig optreedt. Hoofdelijke aansprakelijkheid Indien twee of meer ondernemingen als Combinatie offreren zijn zij hoofdelijk aansprakelijk voor de nakoming van alle uit de overeenkomst of uit de aanbesteding voortvloeiende verplichtingen. Zij 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 penvoerder optreedt in geval van gunning. 4.2 Eisen aan Inschrijvers Verklaringen E4 E5 Indien Inschrijver deel uitmaakt van een concern of holding dient het moederbedrijf ex. artikel 2:403 van het Burgerlijk Wetboek de financiële nakoming te garanderen. Middelen en personeel Indien bij het Offreren door (een onderdeel van) een concern, deze een beroep doet op de referenties, middelen en personeel van moeder-, dochter- en/of zustermaatschappij (een ander van hetzelfde concern), of op natuurlijke of rechtspersonen ongeacht de juridische banden die zij daarmee heeft, ontvangen wij een getekende verklaring van deze Europese aanbesteding , 28 maart

30 betreffende moeder-, dochter- en/of zustermaatschappij, natuurlijke of rechtspersoon dat zij de middelen en personeel ter beschikking zal stellen en dat de Offrerende Inschrijver daar feitelijk over zal kunnen beschikken. E6 Eigendoms- en bestuurssituatie U dient een beschrijving van de eigendoms- en bestuurssituatie van de onderneming bij te voegen, bijvoorbeeld een organigram 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. 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 zekerheidsbijdragen 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. 9 Jegens wie bij een onherroepelijk vonnis of arrest een veroordeling is uitgesproken op grond van artikel 140, 177, 177a, 178, 225, 226, 227, 227a, 227b of 323a, 328ter, tweede lid, 416, 417, 417bis, 420bis, 420ter of 420quater van het Wetboek van Strafrecht van deelneming aan een overheidsopdracht uit. E7 Eigen verklaring Ten bewijze dat Inschrijver niet in één van de bovenstaande omstandigheden verkeert, Europese aanbesteding , 28 maart

31 ontvangen wij een eigen verklaring (zie bijlage 8.11) op grond waarvan Inschrijver zelf aangeeft dat gronden voor uitsluiting niet op Inschrijver van toepassing zijn. E8 Bewijsstukken Inschrijver dient bij de gunning de volgende bewijsstukken op verzoek te overleggen: - Voor het vijfde en 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. E9 E10 Handelsregister 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. Nederlandstalig Inschrijver beschikt over contactpersonen, leidinggevend en trainingspersoneel, dat de Nederlandse taal machtig is Financiële en economische draagkracht E11 Omzet Inschrijver heeft een totale omzet van minimaal vier miljoen Euro (exclusief BTW) in het laatst afgesloten boekjaar. Voor afzonderlijke leden van een Combinatie geldt een minimumeis van twee 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 4-1. 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. De financiële gegevens dienen in Euro s (exclusief BTW) te worden vermeld. Aan de hand van de jaarrekeningen over de laatste drie boekjaren dienen de resultaten en balanstotalen (in duizenden Euro's) zoals vermeld in tabel 4-1 te worden berekend en aldaar te worden ingevuld. Voor een Combinatie geldt dat alle partijen afzonderlijk de betreffende gegevens moeten verstrekken. E12 Financiële draagkracht Inschrijver dient voor de financiële draagkracht te voldoen aan minimaal drie van de vier criteria zoals vermeld in tabel 4-1. 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. Europese aanbesteding , 28 maart

32 Omschrijving resultaat / balanstotaal Kerncijfers jaarrekeningen Grenswaarden Current ratio 1 1,5 in minimaal twee van de drie jaren Solvabiliteit 2 0,25 in minimaal twee van de drie jaren Bruto winst (EBITDA) 3 positief in minimaal twee van de drie jaren 1 miljoen Euro in 2004 en Omzet , 2 miljoen Euro in 2006 Tabel 4-1: kerncijfers 1 Current ratio = vlottende activa / vlottende passiva 2 Solvabiliteit = eigen vermogen / totale activa 3 In duizenden Euro s, exclusief BTW Technische bekwaamheid E13 E14 E15 E16 Vijf referenties Geef een lijst en beschrijving van vijf referenties bij verschillende organisaties uit de afgelopen drie jaar, waar u front- en/of midoffice (klantcontactcentrum- en brokerfunctionaliteit) functionaliteit hebt gerealiseerd. Alle referenties dienen te worden aangeleverd conform het onderstaande model (zie tabel 4-2). Bij de referenties dienen de installatie- en implementatiewerkzaamheden afgerond te zijn. Frontoffice referentie Van deze vijf referenties dient minimaal één referentie een implementatie door de Inschrijver van het aangeboden webintake systeem te betreffen. KCC referentie Minimaal één van de vijf referenties dient een implementatie door de Inschrijver van de aangeboden klantcontactcentrum / DMS applicatie(s) te betreffen. Broker referentie Minimaal één van de vijf referenties dient een implementatie door de Inschrijver van de aangeboden Broker te betreffen. Organisatie Naam van de organisatie Land en plaats van vestiging van de organisatie Publiek / privaat status (bijv. gemeente of bedrijf) Naam en telefoonnummer (verplicht!) van de contactpersoon die in het kader van de referentie kan worden benaderd Opdracht Korte beschrijving van de opdracht Europese aanbesteding , 28 maart

33 Samenhang en integraties applicaties Overzicht van door de Inschrijver geïmplementeerde componenten, inclusief versienummer en / of door de Inschrijver gerealiseerde functionaliteiten. Onderscheid hierbij drie typen werkzaamheden (levering van standaardsoftware, maatwerk en implementatie) Overzicht van de door de Inschrijver geleverde diensten op het gebied van implementatie, onderhoud, support en opleiding Overzicht van de door de Inschrijver gerealiseerde interfaces met externe systemen Aanvang, duur en omvang van de opdracht (inclusief eventuele import, conversie, en/of koppelingen naar andere applicaties), inclusief datum aanvang en datum oplevering 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 werkzaamheden die de Inschrijver zelf tot nu toe heeft uitgevoerd en een schatting van het aandeel in het totale project van de werkzaamheden die door Inschrijver is gedaan Beschrijving van de diensten van eventuele partners die bij de dienstverlening betrokken zijn / waren. 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 Het aantal gebruikers, verbijzonderd per applicatie van de Inschrijver (front- en/of midoffice), alsmede, indien van toepassing, aantal en type gerealiseerde gemeentelijke producten (bijvoorbeeld afschrift GBA ). 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. 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-2: model voor aanleveren referenties De Gemeenten zullen vijf referenties toetsen. De Inschrijver mag dus niet meer referenties op geven. De referenties dienen in samenhang een voldoende beeld te geven van de noodzakelijke Europese aanbesteding , 28 maart

34 (technische) bekwaamheid van de Inschrijver en zullen daarom worden getoetst aan de volgende vijf aspecten: 1. De referentie komt overeen met een door de Gemeenten gevraagde (in omvang en diversiteit) vergelijkbare implementatie van de aangeboden frontoffice en/of midoffice (klantcontactcentrum- en brokerfunctionaliteit) applicatie(s). 2. Het is uitgevoerd in de publieke sector, bij voorkeur lokale overheid (gemeenten). 3. Er is een (voor wat betreft de eindgebruikersinterface) Nederlandstalige versie van de programmatuur opgeleverd. 4. Er is sprake van een implementatie van een combinatie van frontoffice en midoffice (klantcontactcentrum- en brokerfunctionaliteit) functionaliteit. 5. Er is sprake van een implementatie van een combinatie van de aangeboden frontoffice applicatie(s) en de aangeboden midoffice (klantcontactcentrum- en brokerfunctionaliteit) applicatie(s). Europese aanbesteding , 28 maart

35 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, 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 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-, communicatie- en 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 Europese aanbesteding , 28 maart

36 inhoudelijk congruent moet zijn. Uitgangspunt voor het frontoffice is de klant; van daaruit worden de verschillende specialistische onderdelen in het backoffice aangesproken. 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 front- en backoffice wanneer deze functioneel, technisch en/of procesmatig van elkaar gescheiden zijn (de zogeheten knip ). Het midoffice bevindt zich dus tussen het front- en het backoffice in; als zodanig is het een verzameling functionaliteiten die zowel de processen als de bijbehorende applicaties en gegevens in het front- en backoffice met elkaar verbindt. Aldus bewerkstelligt het midoffice één generiek (ont)koppelvlak waarlangs alle fronten backoffice systemen kunnen worden ontsloten. In onderstaande figuur 5.1 is, door middel van een dergelijk midoffice, het aantal benodigde koppelingen tussen N front- en 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. Dun en dik midoffice Figuur 5.1: het midoffice als (ont)koppelvlak 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 en eventueel Europese aanbesteding , 28 maart

37 statusgegevens uit backoffices. 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. 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 5.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 ), web content management, authenticatie (bijvoorbeeld via DigiD) en elektronisch betalen (zoals via Ogone). Het klantcontactcentrum deel omvat naast een gegevens- en een zakenmagazijn bovendien functionaliteiten zoals document management (DMS), workflow management (WfM) en relatiebeheer (CRM). 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 en datadistributie. Europese aanbesteding , 28 maart

38 Figuur 5.2: functionele componenten Midoffice Suite 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 - (Web) content management (CMS) - Webintake - Vraaggeleiding - Product-dienstencatalogus (PDC) incl. zoeken - Authenticatie - Personalisatie - Elektronisch betalen - Geo-informatie (presentatie) - Klantcontactcentrum - Gegevensmagazijn - Zakenmagazijn - Generieke applicatie - Workflow management (WfM) - Document management (DMS) - Relatiebeheer (CRM) - Broker - Broker - Adapters - Datadistributie Europese aanbesteding , 28 maart

39 De huidige situatie verschilt per deelnemende gemeente en wordt als zodanig toegelicht in de afzonderlijke gemeentespecifieke aanvullingen op dit Bestek (zie bijlagen 8.2 t/m 8.5 en paragraaf 8.18 t/m 1.1). 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), willen de Gemeenten daarenboven dezelfde functionaliteit eveneens voor interne dienstverlening, dus aan eigen medewerkers, gaan toepassen. Dit kan bijvoorbeeld betrekking hebben op facilitaire zaken als het reserveren van vergaderruimten, beamers en dergelijke, maar bijvoorbeeld ook op declaratieformulieren, het aanmelden van bezoekers, in-/uitdiensttreding en dergelijke. 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 Frontoffice (Web) content management Elke gemeente heeft een website, vaak zelfs verschillende websites en subsites. Gemeentelijke websites omvatten veel openbare informatie en zijn zonder in te loggen toegankelijk voor de klant. Een web content management systeem (CMS) biedt functionaliteit om content (tekst en afbeeldingen en eventueel ook animatie, audio, video en dergelijke, inclusief de relaties hiertussen) te begeleiden vanaf het moment dat deze, zonder dat kennis van html nodig is, wordt geschreven door ambtenaren en / of externen in de redactieomgeving tot het moment waarop deze in de juiste context (structuur en vormgeving) wordt gepresenteerd in een publicatieomgeving. Content management omvat het ontwikkelen, beheren en publiceren van content. Hier is het onderscheid tussen structuur, vorm en inhoud van groot belang, alsook het onderscheid tussen de redactie- en de publicatieomgeving. Hierbij is ook het hergebruik van vorm, contenttypes en / of inhoud een aandachtspunt. Bij publicatie is niet alleen een gebruiksvriendelijke, mooie, gebruikersinterface in de stijl van de gemeente van belang, een website zou ook aan de Webrichtlijnen van overheid.nl moeten kunnen voldoen. Deze aanbesteding omvat expliciet alleen de CMS software (licenties en basisinstallatie), niet een volledige implementatie. Europese aanbesteding , 28 maart

40 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 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. - 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 Europese aanbesteding , 28 maart

41 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,product-dienstencatalogus en zoeken 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 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. In dit kader is het Samenwerkende Catalogi project van ICTU van belang, alsook het zogeheten no wrong door -principe. Het project Samenwerkende Catalogi is er op gericht om alle productcatalogi van de Nederlandse overheid aan elkaar te linken, zodat de burger of ondernemer vanuit 1 plaats ( no wrong door ) gericht wordt doorverwezen naar de juiste plek in de juiste catalogus. Om hier op aan te kunnen sluiten is het soms nodig dat de gemeentelijke catalogus wordt aangepast z.d.d. deze voldoet aan de Samenwerkende Catalogi standaard. Zoeken heeft in deze context betrekking op het kunnen indexeren en doorzoeken van niet alleen de product-dienstencatalogi maar ook andere gegevens(bronnen) zoals formulieren, websites, (gegevens- en zaken)zakenmagazijnen en andere databases, applicaties, documenten Europese aanbesteding , 28 maart

42 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. 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 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 kan dergelijke functionaliteit ook gebruikt 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. 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 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 Europese aanbesteding , 28 maart

43 aanklikken van een bepaalde locatie in het kader van bijvoorbeeld een melding openbaar gebied 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 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 (bijvoorbeeld over burgers, bedrijven en dergelijke). 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. 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 Europese aanbesteding , 28 maart

44 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 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, Burger Services Nummer (BSN), Bedrijven en Instellingen Nummer (BIN) 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 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 dit dus als het ware 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) met notificatie dat de status is gewijzigd worden verstuurd. 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. Het betreft hier zogeheten horizontale of generieke workflow management functionaliteit (in het klantcontactcentrum), zulks in tegenstelling tot zogeheten verticale of specifieke workflow management functionaliteit (binnen backofficeapplicaties). Aldus kan er worden gestuurd op de afhandeling van bepaalde taken en activiteiten, waarbij bepaalde informatie (zoals procesinformatie, poststukken, s en andersoortige documenten) die bij een bepaalde taak hoort meegeleverd worden. Bij het proces waarin de Europese aanbesteding , 28 maart

45 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 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). Relatiebeheer (CRM) Ten behoeve van het creëren van een integraal klantbeeld over de verschillende kanalen is in het klantcontactcentrum behoefte aan enigszins 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 ( , 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. - 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. Europese aanbesteding , 28 maart

46 - 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. Document management (DMS) Een aantal gemeenten zoekt niet alleen naar document management functionaliteiten ten behoeve van het midoffice, maar ook documentbeheer ten behoeve van de gehele organisatie. Er is aldus niet alleen behoefte aan lichte functionaliteiten en een eenvoudige interface voor de FO/KCC-medewerker, maar ook aan zwaardere functionaliteiten, inclusief workflow, archivering (RMA/DIV) en een interface voor de zogenaamde powerusers. Gemeenten die deze functionaliteit als onderdeel van de onderhavige opdracht willen aanbesteden, zoeken vooral vervanging van hun huidige documentaire informatiesysteem, inclusief postregistratie, ondersteuning van het bestuurlijke proces (RIS/BIS) en dergelijke. Deze gemeenten willen een en ander gaan inzetten als gemeentebrede DMS-oplossing, inclusief invoer van analoge (dat wil zeggen scannen van binnengekomen stukken ten behoeve van het zakenmagazijn) en digitale documenten, postregistratie en dossiervorming (zowel klant- als zaakdossiers), de opslag en het beheer van documenten (inclusief metadata), archivering (RMA) en ondersteuning bij bestuurlijke besluitvorming (RIS/BIS), alsmede workflow management functionaliteit. Het voldoen aan de Archiefwet, maar ook audit trails en dergelijke, is hierbij dan ook een belangrijk aandachtspunt. 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 raads- (RIS) en bestuurlijke informatiesysteem (BIS) zijn bij voorkeur in de website geïntegreerd en te doorzoeken via de zoekmachine van de eigen website en de ICTU (conform Webmetadata standaard). Eventuele andere functionaliteiten zijn het bieden van informatie over de samenstelling van het bestuur (smoelenboek), alsmede over vergaderingen, agenda's etc. van college, raad(scommissies) en dergelijke, inclusief 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, 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 Europese aanbesteding , 28 maart

47 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. NB: 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) 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 front- en 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 publishsubscribe) 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. Daarnaast kan middels zogeheten Business Activity Monitoring (BAM) het proces in de gaten gehouden en zonodig (automatisch) bijgestuurd worden. Bovendien vindt middels logs, audittrails 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, Europese aanbesteding , 28 maart

48 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 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 front- en 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 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 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 validaties) van die betreffende backoffice applicatie. Synchronisatie- en statuskoppelingen kunnen, in tegenstelling tot transactiekoppelingen, wel via adapters op basis van databasekoppelingen worden gerealiseerd De Gemeenten hebben bovendien de intentie om gezamenlijk adapters van alle voornoemde typen te (laten) ontwikkelen en onderling uit te wisselen Datadistributie Backoffice systemen hebben veelal dezelfde objecttypen en objectgegevens (zoals adresgegevens van een persoon of bedrijf) in steeds verschillende syntax, semantiek en kwaliteitsniveaus. Backoffice applicaties hebben nauwelijks voorzieningen om hun gegevensmutaties afdoende te afstemmen en distribueren. Een datadistributievoorziening biedt functionaliteit voor het distribueren van (basis)gegevens tussen backoffice applicaties onderling en naar het gegevensmagazijn. In deze context kunnen backoffice applicaties zowel gegevens leverancier als -afnemer zijn, inclusief de bijbehorende regels. Europese aanbesteding , 28 maart

49 5.2 Eisen Midoffice Suite E17 Implementatiepartijen Inschrijver garandeert dat er minimaal twee partijen (exclusief de Inschrijver en zusterdochter en moedermaatschappijen) zijn die de aangeboden applicatie(s) in de fase na Initiële implementatie bij de Gemeenten kunnen implementeren en ondersteunen. Geef ter onderbouwing aan welke partijen dat kunnen zijn. E18 Toekomstige ondersteuning Inschrijver garandeert de toekomstige ontwikkeling en ondersteuning van de aangeboden Midoffice Suite software en de continuïteit van de software leverancier(s). Dit bijvoorbeeld door een onderbouwing te geven over de mate waarin de aangeboden applicatie(s) en de bijbehorende ontwikkelaar / leverancier toekomstvast is in termen van product- en bedrijfstrategie en de daarbij behorende ontwikkelinspanning voor de komende jaren, inclusief 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. 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 Databases en -servers: Oracle 9i op diverse operating systemen, of Microsoft SQL Server 2000 of Europese aanbesteding , 28 maart

50 5.3 Vragen Midoffice Suite: frontoffice 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 XForms). 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. NB: beoordeling van de vraag vindt onder meer plaats op basis van de mogelijkheden om op eenvoudige wijze geavanceerde elektronische formulieren te creëren (logica en intelligentie, inclusief overerving, etc.) met een strikte scheiding van vorm en inhoud. 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. Indien het mogelijk is om formulieren in andere formaten om te zetten (zie ook vraag V1), geef dan aan of en hoe deze formulieren, die niet middels het webintake systeem zijn gepubliceerd, worden beheerd vanuit één beheermodule. 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. NB: beoordeling van de vraag vindt onder meer plaats op basis van de mogelijkheden om op eenvoudige wijze elektronische formulieren zoveel mogelijk centraal te beheren Europese aanbesteding , 28 maart

51 (versiebeheer, workflow, metadata en dergelijke) met een fijnmazig overerving- en autorisatiemodel. 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. Beschrijf de import- en 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). NB: de beoordeling vindt plaats op basis van de relevantie voor Gemeenten en de mate van onafhankelijkheid en behoud van functionaliteit met betrekking tot import- /exportmogelijkheden.. V4 * Formulierexecutie: basisfunctionaliteiten Beschrijf of en zo ja de mate waarin gebruikers kunnen worden ondersteund 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, 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 of en zo ja de mate waarin de formulieromgeving mogelijkheden biedt m.b.t. 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 niet-standaard validaties. Geef aan of, en zo ja hoe, zogeheten hidden fields kunnen worden gebruikt Europese aanbesteding , 28 maart

52 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 taal-parameter bij het starten van een formulier, zodat het slechts eenmaal hoeft te worden onderhouden). V6 * Formulierverwerking Beschrijf of en de mate waarin 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 g d worden), ontvangstbevestigingen en dergelijke. Geef aan hoe de ingevulde gegevens naar het midoffice getransporteerd worden (bijvoorbeeld via XML, XForms, , 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 text 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 / 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 en eventuele digitale handtekeningen (of andere manieren van authenticatie) daarbij. V7 * KCC formulieren Beschrijf de mogelijkheden om webformulieren in te zetten bij alle kanalen, inclusief post (postregistratie), balie, telefoon (callcenter) en . 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 management en - tracking, zoals het monitoren van inkomende , het volgen, doorgeleiden en/of afhandelen van en het bewaken van servicenormen (zoals de antwoordtermijn). Europese aanbesteding , 28 maart

53 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/KCCmedewerker of andere medewerkers gebruik kunnen 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, thema, levensgebeurtenis, via een kaart (op coördinaat), middels zoeken en dergelijke. NB: beoordeling van de vraag vindt onder meer plaats op basis van de mogelijkheden om op eenvoudige wijze vraaggeleiding te kunnen ontwerpen en (centraal) te beheren, alsmede om klanten én FO/KCC-medewerkers te helpen bij het zoeken en vinden van de juiste informatie. 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. Geef bovendien aan welke additionele informatie uitsluitend beschikbaar kan worden gemaakt voor geautoriseerde medewerkers (zoals werkinstructies, procesbeschrijvingen en dergelijke). Beschrijf de functionaliteiten om een PDC op te zetten, te beheren en aan klanten aan te bieden; denk hierbij ook aan versiebeheer, autorisatie en dergelijke. 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 er sprake is van een standaard vulling van de PDC en / of het voor gemeenten mogelijk is zich te abonneren op updates (1P en/of 3P) van de PDC en geef aan wat de mogelijkheden zijn om de standaardvulling aan te passen en of het inlezen van dergelijke updates kan zonder enige reeds aanwezige gemeentespecifieke aanpassingen teniet te doen. NB: beoordeling van de vraag vindt onder meer plaats op basis van de mogelijkheden om op eenvoudige wijze een PDC te ontwikkelen en (de)centraal te beheren, inclusief een fijnmazig autorisatiemodel (ook voor ontsluiting). 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 ook het Samenwerkende Catalogi project van ICTU, het zogeheten no wrong door -principe en de ontwikkelingen rondom gemeentelijke klantcontactcentra die in de toekomst ook (informatie over) producten van derden zoals andere (semi-)overheden, nutsbedrijven en dergelijke zouden moeten gaan leveren (het zogeheten Contact Center Overheid oftewel CCO). 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. Europese aanbesteding , 28 maart

54 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), maar ook over hoe om te gaan met niet-ingezetenen. 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 NAWgegevens 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 WOZportaal kan gaan dat in een ASP-omgeving draait. Geef bovendien aan of, en zo ja hoe, FO/KCC-medewerkers klanten kunnen authenticeren bij telefonisch, of baliecontact en bijvoorbeeld aldus namens hen producten kunnen aanvragen. Geef aan in hoeverre het (op termijn) mogelijk is PKI te gebruiken voor authenticatie van medewerkers, burgers en/of bedrijven. 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 geef aan welke mogelijkheden er worden geboden voor statusvolging door de aanvrager van een ingediend formulier. Denk hier bijvoorbeeld aan re- en proactieve notificatie c.q. attendering op het dreigende verstrijken van deadlines en dergelijke (zoals uw rijbewijs verloopt eerdaags ), inclusief het gebruik van een interesseprofiel van de klant (zoals bijvoorbeeld een overzicht van nieuws dat binnen dit interesseprofiel valt). Maak hierbij ook, indien van toepassing, onderscheid per kanaal (zoals web, , post en dergelijke). Geef ook aan of, en zo ja hoe, klanten half ingevulde en/of reeds verzonden formulieren en de status van processen hieromtrent kunnen bekijken (zoals deadlines, stadia en dergelijke). Europese aanbesteding , 28 maart

55 Beschrijf de mogelijkheden rondom het opvragen en weergeven van persoonlijke en/of gepersonaliseerde informatie uit verschillende bronnen. Dit kunnen, naast het zaken- en gegevensmagazijn en documenten in het DMS, ook andere achterliggende systemen zijn, die bij voorkeur via de broker worden ontsloten. Geef aan welke informatie klanten kunnen opvragen/inzien alsmede of, en zo ja hoe, klanten en medewerkers de mogelijkheid hebben om aanvullingen en correcties op dergelijke 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. Geef bij het ontsluiten van DMS-documenten aan waar die documenten zich daadwerkelijk bevinden (in het DMS zelf, als kopie in de DMZ of elders). 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). Betrek hierbij ook koppeling met en gebruik van functionaliteiten zoals het ICTU project Persoonlijke Internet Pagina (PIP); voor een toelichting op dit project, zie Zoeken V12 Zoeken en indexeren Beschrijf welke functionaliteit standaard geboden wordt ter ondersteuning van zoeken in CMS, PDC, formulieren en achterliggende bronnen (gegevens- en zakenmagazijn, DMS, databases, applicaties, PDF-, Word- en eventuele andere documenten, etc) en geef aan of, en zo ja hoe en in hoeverre, hierbij rekening gehouden kan worden met autorisaties, rechten en rollen (zoals openbaar, inwoner van de gemeente, specifieke klant, bepaalde medewerkerrollen, etc) 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, alsmede verder zoeken binnen de zoekresultaten), 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) te importeren en/of anderszins te gebruiken. Indien aanvullende zoekfunctionaliteiten mogelijk zijn door gebruik van 3P producten, beschrijf deze voor alle rollen (klant, FO/KCC-en andere medewerkers, beheerder en dergelijke) en geef aan wat de consequenties zijn van het inzetten van de betreffende 3P producten. NB: zoeken dient bij voorkeur autorisaties te respecteren (zowel van klanten als van medewerkers) en kan onder meer webcontent, de PDC en (deels) het zakenmagazijn door klanten te laten doorzoeken en naar hen ontsluiten. Medewerkers kunnen bij voorkeur ook additionele bronnen doorzoeken.. Europese aanbesteding , 28 maart

56 5.3.5 Web Content Management V13 Content creatie Geef aan over welke functionaliteiten het aangeboden product zelf beschikt aangaande het maken en bewerken van content in het CMS ( native content editor ). Bespreek hierbij onder andere de mogelijkheden met betrekking tot centrale vs. decentrale redactie, in-context editing, wysiwyg (incl. opmaak, tabellen, lijsten, etc), uit Word en Excel kopiëren (incl. opmaak), tabellen, URL s, etc. Beschrijf ook de functionaliteit met betrekking tot versiebeheer, check in / check out en dergelijke en besteed hierbij ook aandacht aan back-up, archivering en roll-back (in de redactieomgeving). Bespreek hierbij ook het aanmaken van shortcuts (friendly URL's) naar diepgelegen pagina's, batchimport en -export van te koppelen documenten/plaatjes en doorvoeren van wijzigingen in meerdere pagina s tegelijk. Beschrijf hierbij ook de mogelijkheden interne en externe links te maken en actueel te houden, inclusief automatische controle op dode links en links naar documenten in het DMS (specifieke versies of juist altijd de meest recent vrijgegeven versie). Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning (flexibiliteit) van workflow voor redactie en publicatie aangaande het definiëren en wijzigen van een business-/werkproces inclusief de rollen, procesgang, parallelle en sequentiële werkstromen, overerving, rappelfunctie, notificatie, publicatie, expiratie, bypass voor hoger geauthoriseerden etc. Geef tevens aan wat de mogelijkheden zijn voor het bewerken van workflow en importeren van workflow uit andere systemen. Geef aan over welke mogelijkheden het aangeboden product beschikt om een beheersorganisatie in te richten (rechten en rollen), inclusief structuren die gebruikt worden om het geheel overzichtelijk te houden en de mogelijkheid om doorsneden van redacteuren te definiëren in relatie tot diverse domeinen. Geef aan welke eisen er moeten worden gesteld aan kennis en competenties van de beheerders en welke eisen er aan de beheers(client)omgevingen worden gesteld voor o.a. (centraal en decentraal) aanmaken/beheren van content, contenttypen, workflow, vormgeving en koppelingen. Geef ten slotte ook aan of, hoe en welke 3P content editors worden ondersteund en op welke wijze content offline te beheren is. V14 * Content repository en contenttypen Beschrijf de mogelijkheden om contenttypen te ontwikkelen en beheren. Vermeld tevens de mogelijkheden van de (native) contenttype editor voor overerving en het wijzigen van contenttypen uit andere domeinen. Geef aan welke functionaliteit het aangeboden product bevat voor de ondersteuning van metadata met betrekking tot content, incl. het bijhouden van de oorspronkelijke auteur, oorspronkelijke datum van aanmaak, titel, samenvatting, doelgroep, publicatie- en archiveringdatum, trefwoorden, publicatiekanaal, wijzigingshistorie en dergelijke. Geef aan in welke mate functionaliteit beschikbaar is ter ondersteuning van verplichte en nietverplichte metadata, per contenttype, per content item, standaard metadata en het automatisch creëren van metadata; geef hierbij bovendien aan of en zo ja hoe de metadata separaat beheerd kan worden van de content. Europese aanbesteding , 28 maart

57 Beschrijf of en zo ja en hoe rekening gehouden kan worden met verschillende talen (Nederlands, Duits, Engels, etc.) in de beheers- en publicatieomgeving. Geef aan in welke mate het product ondersteuning biedt voor standaarden zoals Dublin Core (extended) en NL.META. NB: de voorkeur gaat uit naar een krachtige repository en editor met alle bovengenoemde functionaliteiten, een editor die rekening houdt met hetzelfde soort bericht in verschillende talen, waar standaard gebruik gemaakt kan worden van de genoemde metadata, etc. V15 Content Publicatie Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van navigatie aan de publicatiekant, inclusief meerdere navigatietypen binnen de site, navigatiebomen, kruimelpad etc. Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van automatisch gegenereerde sitemaps, inclusief configureerbaarheid, diepte, opbouw (realtime of niet) en weergave op basis van domein van de bezoeker. Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van de aanmaak en het onderhoud van definities m.b.t. lay-out, inclusief werken met templates of sjablonen, mate van ondersteuning van de huisstijl (voorgeschreven geheel van opmaak, navigatie en toegestane structuur) van de verschillende gemeenten, flexibiliteit voor incidentele aanpassingen, vormgeving van de navigatiestructuur en overerving naar subdomeinen (terugkerende stijlelementen) en de mogelijkheden voor afwijkingen. Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van content scheduling, staging en preview van pagina s en structuur. Geef daarbij ook aan of het mogelijk is om de lifecycle van de content en separaat daarvan de vormgeving op te geven en automatische te verwijderen indien deze verstreken is. Geef aan op welke manier multi-channel publicatie (zoals webbrowsers, PDF, , printerfriendly pagina's, druk- en printwerk (ook gepersonaliseerd en on-demand), PDA, GSM, SMS, flash, RSS, webcasting, narrowcasting, etc.) wordt ondersteund. V16 * Multidomein en multisite support CMS Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van verschillende domeinen en subdomeinen (zoals bijvoorbeeld de gemeentesite, het e- loket en een tijdelijke evenementensite) inclusief ondersteuning van zowel een meervoudige beheersomgeving als ook een meervoudige publicatieomgeving vanuit één centrale repository. Beschrijf hierbij tevens de mogelijkheden voor overerving (van contenttypes, opmaak, structuren, workflow, etc.), eigenaarschap content, uitwisseling content tussen domeinen, rollen en rechten structuur binnen en over domeinen. Bepreek hierbij ook het beheer van templates per content element voor multi-channel toepassingen. Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning voor alle sites (bijv. intranet en extranet) en subsites Europese aanbesteding , 28 maart

58 (bouw.gemeentex.nl van met hergebruik van contentitems (single source publishing op basis van een 1:N relatie). Geef aan over welke functionaliteit het aangeboden product beschikt om vanuit één beheersomgeving content te pushen naar verschillende (meerdere) publicaties en wat de mogelijkheden zijn om vanuit een publicatie-omgeving content te pullen uit verschillende beheersomgevingen. Geef aan over welke functionaliteit het aangeboden product beschikt ter ondersteuning van hergebruik van content (dus niet alleen de contenttypes) en hoe daarbij de integriteit van content wordt gewaarborgd, ook bij in-context-editing. Beschrijf de mogelijkheden voor wat betreft syndicatie van content, dus het weergeven van content van buiten de organisatie en het aan andere sites aanbieden van content (bijvoorbeeld middels RSS). V17 * Raadsinformatiesysteem Geef aan hoe de organisatie van het bestuur, zoals bestuurs- en adviesorganen, hun achtergrondinformatie (personen, partijen, visie etc.) en dergelijke kan worden weergegeven op internet en intranet. Beschrijf de functionaliteiten om thematisch dossiers in te zien, waarbij kan worden doorgeklikt naar onderliggende stukken. Houdt hier rekening met processtappen (bepaalde informatie afhankelijk van de status alleen beschikbaar in het intranet), autorisatieniveaus (raadsleden, collegeleden, groepen medewerkers, burgers, etc.) op contentitem- en op documentniveau, etc. Beschrijf hoe het systeem de mogelijkheid biedt inzicht te verschaffen in vergaderingen, agenda s en de daaraan gekoppelde documenten. Beschrijf de mate waarin het systeem ondersteuning biedt voor communicatie tussen leden van de gemeenteraad, burgers enz. via doelgroepgerichte en thematische ingangen. Denk hier ook aan interactieve diensten (blogs, fora, wiki s, etc.). Beschrijf hierbij de relatie tussen CMS en DMS, zie ook V Geo-informatie presentatie V18 * Presentatie geo-informatie 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 worden gerelateerd (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 andere medewerkers, etc. met de bijbehorende rechten. Europese aanbesteding , 28 maart

59 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 video- en geluidsfragmenten). Beschrijf hierbij tevens de mogelijkheden voor de integratie van webcontent en -formulieren, documenten en geo-informatie; denk bijvoorbeeld aan het kunnen aanklikken van een locatie in het kader van een melding openbaar gebied of het tonen van (informatie over) een specifieke bouwvergunning wanneer het betreffende pand wordt geselecteerd in de GIS-viewer. Denk hierbij ook aan prefill van relevante gegevens op een formulier (zoals het adres van de betreffende melding), de verschillende coördinatenstelsels zoals RD en WGS84 en het printen van de resulterende kaart. Geef aan of weergave van gegevens afhankelijk kan zijn van het zoomniveau, zoals gegevens over een specifiek adres bij maximaal inzoomen, een overzicht van bouwvergunningen op zoom op straatniveau, etc. Maak bij de beantwoording van deze vragen, indien van toepassing, een onderscheid tussen de verschillende rollen (zoals klant, medewerker en dergelijke). Beschrijf de mogelijkheden voor het gebruik van luchtfoto s, cyclorama foto s, extern aangeboden services (Google Maps, risicokaarten, etc.) en dergelijke, inclusief de projectie van objecten hierop. Beschrijf tevens de mogelijkheden voor het gebruik van functionaliteiten zoals zoomen, pannen, selecteren (punt, lijn en/of vlak), identify, bookmarks, opslaan en/of exporteren, afdrukken (incl. schaal, etc.) en het gebruik van geografische operatoren zoals cross, contain, touch, buffer, clip en intersect. Maak bij de beantwoording onderscheid tussen de rollen klant en medewerker. Beschrijf de mate waarin door de geoffreerde applicatie(s) voor de presentatie van geoinformatie gebruikgemaakt wordt van al dan niet domeinspecifieke (open en defacto) standaarden (incl. versies van standaarden). Geef aan welke formaten ondersteund worden, zoals dwg, dxf (Autocad), dgn (Microstation), e00 (coverage files Arcinfo), shp (Arcview/Arcgis), mif/mid (MapInfo) en bna, maar ook jpg, png, gif, bmp, tiff, geotiff, ecw (Enhanced Compressed Wavelet), Mrsid (Multi-Resolution Seamless Image Database) en 360 graden panorama foto's (cyclorama's). Geef hier ook aan welke koppelingen en uitwisseling naar externe en interne databronnen mogelijk zijn, denk dan aan gml (Open Gis Consortium), sde, Oracle Spatial, Open Geospatial, Google Maps / Google Earth, NEN-*, WebGIS, ISO TC211, IMRO 200x, geodatabase, structured text, etc. maar ook database files zoals Access, Foxpro, etc. en verschillende DBMS en Elektronische betalen V19 Elektronisch betalen Geef aan welke ondersteuning geboden wordt voor betaling via Ogone, inclusief alle ondersteunde betaalmethoden (zoals ideal, eenmalige machtiging, acceptgiro, creditcard, etc). Geef bovendien aan of u nog andere manieren van betalen ondersteunt dan via Ogone en zo ja welke, wederom inclusief ondersteunde betaalmethoden. 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 Europese aanbesteding , 28 maart

60 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 en 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.2). 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 gegevensen/of zakenmagazijn, in een (zaak)dossier en dergelijke Overig V20 Additionele functionaliteiten frontoffice Hier kunt u additionele functionaliteiten van de aangeboden applicatie(s) beschrijven die in het kader van paragraaf 5.3 weliswaar relevant zijn maar waar niet specifiek naar gevraagd wordt. Beschrijf hier de eventuele geavanceerde enquêtefunctionaliteit (ten behoeve van in- en extern klantonderzoek) die het geoffreerde CMS standaard biedt, inclusief de mogelijkheden om gegeven antwoorden te exporteren (bijvoorbeeld naar SPSS, Excel, etc.). Beschrijf hier ook eventuele additionele frontoffice functionaliteiten en/of add-ons zoals (automatische) FAQ-generatie, wiki s, fora (op intranet en/of internet), blogs, eenvoudige polls en dergelijke. 5.4 Vragen Midoffice Suite: klantcontactcentrum Gegevensmagazijn V21 * Inrichting gegevensmagazijn 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 roll-back 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. Europese aanbesteding , 28 maart

61 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), alsmede voor buitenlandse en buitenlands gevestigde personen en bedrijven. Zie ook V49 en verder. 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 bovendien aandacht aan de rol die het gegevensmagazijn kan spelen bij zogeheten datadistributie (zie ook V49 en verder) en of de gegevensdefinities conform de basisregistraties (zoals BAG) zijn in te richten. V22 * Ontsluiting gegevensmagazijn Beschrijf de mogelijkheden voor het opzoeken en ontsluiten van gestructureerde (basis)gegevens (velden / records) uit het backoffice, een GIS datawarehouse en dergelijke via het gegevensmagazijn. Denk aan de gebruikelijke (basis)registraties, WOZgegevens, 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). Europese aanbesteding , 28 maart

62 Denk hierbij ook aan de registratie, bijhouding en uitwisseling van publiekrechtelijke beperkingen in het kader van de WKPB. Geef hierbij tevens aan wat eventuele consequenties zijn voor de aangeboden Midoffice Suite, met name voor wat betreft de voor- en nadelen van een dergelijke werkwijze, indien een gemeente het gegevensmagazijn zou willen vullen middels een (evt reeds aanwezige) datadistributievoorziening zoals Centric DDS4all of PinkRoccade BRS, of middels reeds aanwezige ETL-tools. V23 # Geo-informatie magazijn 4 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. Onderscheid hier een contourendatabase en een mapserver. Beschrijf hoe gekoppeld kan worden met geografische informatiesystemen in het backoffice, zoals die van Bentley, ESRI, etc. Beschrijf de wijze waarop wordt omgegaan met een koppeling naar een al aanwezige GIS-viewer (zoals Flexiweb, Flexiweb 2006, Geo Web Solutions, ArcIMS, ArcGIS server Standard, Flamingo, Google Earth). Geef hierbij tevens aan of en hoe gebruik kan worden gemaakt van landelijke bronnen. 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 en / of defacto) standaarden (incl. versies van standaarden). Geef aan welke formaten ondersteund worden, zoals dwg, dxf (Autocad), dgn (Microstation), e00 (coverage files Arcinfo), shp (Arcview/Arcgis), mif/mid (MapInfo) en bna, maar ook jpg, png, gif, bmp, tiff, geotiff, ecw (Enhanced Compressed Wavelet), Mrsid (Multi-Resolution Seamless Image Database) en 360 graden panorama foto's (cyclorama's). Geef hier ook aan welke koppelingen en uitwisseling naar externe en interne databronnen mogelijk zijn, denk dan aan gml (Open Gis Consortium), sde, Oracle Spatial, Open Geospatial, IMGeo, Google Maps / Google Earth, NEN-*, WebGIS, ISO TC211, IMRO 200x, geodatabase, structured text, etc. 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. Geef hier ook aan hoe u om gaat met verschillende coördinatenstelsels die in een gemeente bestaan, zoals het RDstelsel en WGS84. 4 Zie paragraaf voor betekenis van de # Europese aanbesteding , 28 maart

63 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 klant- en zaakdossiers (bijvoorbeeld links naar documenten in een DMS, zoals correspondentie over de betreffende zaak, bij de aanvraag meegestuurde bijlagen en dergelijke). V24 * Inrichting zakenmagazijn Beschrijf de inrichting van het zakenmagazijn. Denk hierbij aan zaken als plaatsing, datamodel (zoals gestructureerde en ongestructureerde gegevens, verwijzingen naar externe bronnen en dergelijke, inclusief de relaties tussen de verschillende elementen van een zaak en tussen zaken onderling), 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. Beschrijf hierbij ook hoe wordt omgegaan met de verschillende zaak-id s die in backoffices kunnen voorkomen, en of en hoe er binnen de midoffice suite sprake is van één zaakaanduiding (en hoe er dan wordt omgegaan met subzaken). 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), klantcontacten, aanduidingen van geo-informatie (coördinaten: punten, contouren en vlakken) en verwijzingen naar externe bronnen (zoals basisregistraties, het gegevensmagazijn, documenten in een DMS en dergelijke), etc. 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). Geef hierbij aan hoe dit zich verhoudt tot de verschillende onderdelen van de Midoffice Suite, zoals FAQ s, de PDC en in het bijzonder (indien relevant) een CRM-systeem. V25 * Ontsluiting zakenmagazijn Beschrijf of, en zo ja hoe, de geoffreerde applicatie(s) medewerkers, óók in het backoffice, 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 medewerkers hierbij kunnen 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 Europese aanbesteding , 28 maart

64 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 zoals bij een Melding Openbaar Gebied). Beschrijf hoe FO/KCCen andere medewerkers kunnen zoeken op bijvoorbeeld product, klant of een combinatie van beide. 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. V26 * Dossiervorming Beschrijf de mogelijkheden tot dossiervorming in het zakenmagazijn, zoals aangaande ingevulde formulieren en bijlagen (inclusief aanvraagresultaat en procesinformatie) en aanvullende documenten zoals correspondentie, s en dergelijke. 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 Workflow management V27 * 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, (beheer van) business rules 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 Europese aanbesteding , 28 maart

65 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. V28 * 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. 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. Geef aan hoe hier business rules gebruikt kunnen worden. Beschrijf van welke interfaces zoals gebruikgemaakt kan worden, zoals webinterface, maar ook clients (bijvoorbeeld ten behoeve van incidentele accorderingen). 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), waarbij ook state en de gebruikte regels en workflow worden gelogd. 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. V29 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 Europese aanbesteding , 28 maart

66 hierbij ook aandacht aan eventuele mogelijkheden om procesmodellen uit te wisselen met andere gemeenten Relatiebeheer V30 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, verschillende telefoonnummers, adres, locaties (zoals coördinaten, adressen en dergelijke), alsmede zogeheten flexvelden. Geef bovendien aan waar een en ander daadwerkelijk wordt opgeslagen. Beschrijf de mogelijkheden voor het modelleren van relaties tussen objecten zoals klanten, bedrijven, contactpersonen en dergelijke. Bespreek hier onder meer de relatie met het gegevens- en zakenmagazijn, het BBR en andere (basis)registraties. Beschrijf bovendien de mogelijkheden ten aanzien van het opschonen, ontdubbelen en dergelijke van data. V31 * 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 betrokken medewerker / afdeling (afhankelijk van het gemeentelijke product ) en het starten van processen ter voorbereiding van de desbetreffende afspraak. Denk hierbij onder meer aan zaken als integratie met de PDC, eventuele prefill van reeds bekende (persoons- en/of product)gegevens in de afspraak, etc. 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 en / of Novell GroupWise. V32 * Contactregistratie Geef aan welke functionaliteit u biedt voor het registreren van klantcontacten, het opbouwen van klantprofielen en dergelijke. Geef hierbij aan welke klantcontacten geregistreerd worden, op welke wijze en 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- mailadres en dergelijke). Geef aan of en hoe deze registratie ook niet-productgerelateerde klantcontacten omvat, zoals vragen over openingstijden. Beschrijf de verschillende kanalen waar een klantcontactcentrum gebruik van kan maken voor inkomende en/of uitgaande klantcontacten. Denk aan , telefoon, web, post, Europese aanbesteding , 28 maart

67 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), realtime of na batchsynchronisatie. Geef aan of er beperkingen zijn m.b.t. de door de klant te kiezen kanalen 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. Geef hierbij aan of en hoe onderscheid kan worden gemaakt tussen de verschillende rollen van eenzelfde persoon, zoals iemand die eerst als individu en later als secretaris van een vereniging een verstuurd. Beschrijf ten slotte hoe de functionaliteit voor contactregistratie en klantdossiers zich verhoudt tot alle andere onderdelen van de Midoffice Suite. V33 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 workflow management functionaliteit en het zakenmagazijn. V34 Call management Beschrijf de mogelijkheden voor call management. Denk hierbij onder meer aan het beheer van callcenter agents (telefonistes m / v), CTI (zoals contactregistratie en het automatisch tonen van klantinformatie, inclusief eventuele bijbehorende zaakinformatie en -dossiers op basis van nummerherkenning), VOIP, (Automatic) Call Distribution, Interactive Voice Response, etc. Beschrijf tevens de mogelijkheden ten aanzien van rapportages hieromtrent, bijvoorbeeld in het kader van SLA s. Denk hierbij aan aantal openstaande calls, aantal opgeloste calls en dergelijke. Beschrijf de wijze (functioneel en technisch) waarop gekoppeld kan worden met telefooncentrales. Zie bijlage 8.2 voor de merken en typen telefooncentrales waarvoor dit in ieder geval beschreven zou moeten worden. NB: een hechte integratie in de look&feel van de medewerker heeft de voorkeur. V35 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 Europese aanbesteding , 28 maart

68 relatiebeheer- (CRM), content management- (CMS), vraaggeleidings- (PDC) en/of webintake-applicatie(s). Beschrijf in ieder geval de koppelmogelijkheden van en de relatie tussen CRM en de Midoffice Suite, alsmede de mogelijkheden voor medewerkers om van de selfservice functionaliteiten gebruik te maken. NB: krachtige doch eenvoudig in gebruik zijnde en zoveel mogelijk met de overige suite geïntegreerde onderdelen hebben de voorkeur Generieke applicatie V36 * Generieke applicatie Beschrijf of, en zo ja hoe, backoffice-loze producten zoals eenvoudige vergunningen kunnen worden afgehandeld met de Midoffice Suite als generieke applicatie. Denk bijvoorbeeld aan elektronische formulieren, werkprocessen (inclusief workflow zoals een beperkt aantal statussen en een checklist per status), 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). NB: een krachtige omgeving met eenvoudige en eventueel uitgebreide workflows, statussen, etc. heeft de voorkeur Document management Een aantal van de Gemeenten wil het geoffreerde DMS inzetten ter vervanging van het huidige documentaire informatiesysteem. Daarnaast wil een aantal Gemeenten het geoffreerde DMS (op termijn) ook in gaan zetten als een gemeentebrede DMS / RMA applicatie. Hierbij dient het DMS niet alleen voor postregistratie en dergelijke, maar bovendien als gemeentebreed documentplatform en (digitaal) archief. E22 De geoffreerde DMS / RMA applicatie voldoet aan de zogeheten ReMANO eisen, ook voor wat betreft functionaliteiten welke niet expliciet worden uitgevraagd in het Bestek. NB: feitelijke certificering is hier niet vereist. V37 * 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 Europese aanbesteding , 28 maart

69 verrijking van gescande documenten met metadata. Denk ook aan eventuele OCR en ICR en het automatisch toevoegen van metadata (maskeren). 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, maar bijvoorbeeld ook aan de Basis Archief Code). Geef aan in hoeverre metadata zelf benoemd kan worden (gebruik van vaste registratieschermen versus eigen ontwerp). Geef aan hoe bij een bulk scan documenten kunnen worden gescheiden, denk hierbij aan het gebruik van barcodes op tussenbladen. Geef ook aan of en in hoeverre het mogelijk is om automatisch samenvattingen te genereren en deze als metagegeven op te nemen. V38 * 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. Bespreek hier tevens postregistratie van digitale post middels . V39 Invoer digitale documenten Beschrijf de mogelijkheden rondom invoer van digitale documenten inclusief . Denk aan bulkinvoer (inclusief foutafhandeling), koppelingen met externe applicaties zoals kantoorautomatisering (MS Office, OpenOffice, etc) inclusief groupware (zoals e- mailclients ), verplichte en/of facultatieve metadatering (obv een taxonomie, vrij velden, standaardwaarden en dergelijke) inclusief metadata van berichten, ondersteunde documentformaten en dergelijke. Denk ook aan ODMA, WebDAV en dergelijke. Geef aan of, en zo ja hoe, gebruik gemaakt kan worden van documentsjablonen. V40 * Documentopslag en -beheer Beschrijf de mogelijke repository / repositories van documenten. Maak onderscheid tussen technieken (fysieke opslag, 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 backup, 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 opslag in standaardformaten zoals PDF(/A), inclusief eventuele dubbele opslag naast het originele formaat. Geef in dat laatste geval ook aan hoe wordt omgegaan met de translatie van documenten. Europese aanbesteding , 28 maart

70 V41 * Dossiervorming en archivering Beschrijf de mogelijkheden voor dossiervorming van stukken bij een product / zaak. Maak onderscheid tussen stukken die een burger kan zien en stukken die uitsluitend medewerkers kunnen zien, alsook tussen zogeheten warme (dynamische) en koude (semi-statische) dossiers. Geef aan of een DSP onderdeel uitmaakt van het DMS/RMA en beschrijf, indien van toepassing, welke mogelijkheden dit biedt, alsmede of en zo ja hoe er een koppeling kan worden gemaakt met procesbeschrijvingen (bijvoorbeeld in Protos, BWise of Mavim) en/of de WfM-functionaliteit. 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. Beschrijf tevens de mogelijkheden ten aanzien van het archiveren van documenten en dossiers (incl. zaakgerelateerde gegevens buiten documenten) en maak hierbij onderscheid tussen document- en procesgericht archiveren. Beschrijf hoe in het kader van digitale duurzaamheid de authenticiteit wordt gewaarborgd. Denk hierbij aan eventuele wettelijke eisen, zoals ReMANO, de Archiefwet, DSP s en de zogeheten basis selectielijst (bijvoorbeeld van de VNG) en besteed hierbij ook aandacht aan vernietiging conform de daartoe geldende wet- en regelgeving. Vermeld tevens alle eventuele relevante certificeringen van uw product(en), bijvoorbeeld ReMaNo, DoD ( STD) of NEN-ISO (zoals :2001 en 20289). Beschrijf ten slotte de mogelijkheden voor het archiveren van webcontent (van de website). V42 * Ontsluiting DMS 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 (thesaurus) en dergelijke. Geef aan of, en zo ja in hoeverre, de zoekfunctionaliteit gebruik maakt van een taxonomie en/of synoniemenlijst. Geef ook aan welke mogelijkheden er zijn voor het inzien, printen en dergelijke van gegevens, inclusief overzichten zoals rappellijsten en dergelijke. Beschrijf of en hoe het bij ingescande afbeeldingen zoals bouwtekeningen mogelijk is om een schaal op te nemen (x bij y pixels = n bij m cm) en zo afstanden te meten aan de hand van deze schaal. Geef hierbij ook aan welke gegevens moeten worden ingevoerd om dit opmeten te kunnen doen. Beschrijf tevens de mate waarin de applicatie voorziet in het op schaal printen/ plotten van een selectie van een digitale tekening. Geef tevens aan of dit ook in een andere schaal (of percentage van de oorspronkelijke schaal) kan gebeuren. Geef Europese aanbesteding , 28 maart

71 hierbij aan of en welke afhankelijkheid bovenstaande kent in relatie tot de wijze waarop gescand wordt (centrale scanstraat, door een klant ingescande tekening, etc.). Beschrijf de mogelijkheden om het DMS te gebruiken als documentopslag voor backoffice applicaties, waar dus deze backoffice applicaties gebruik maken van het DMS om documenten in op te slaan die binnen de verticale processen worden gebruikt. Besteed hier tevens aandacht aan ontsluiting via het web (inter- en intranet), inclusief, koppeling met CMS, webintake systeem en/of GIS (bijvoorbeeld om, wanneer een bepaald object wordt aangeklikt op de kaart, de daadwerkelijke vergunningen te tonen die daarbij horen). Denk ook aan zaken als publicatietermijnen, de ontsluiting van al bestaande (klant- en zaak)dossiers en dergelijke. Besteed hierbij tevens aandacht aan ontsluiting van documenten gekoppeld aan bestuurlijke vergaderingen en agenda's. N.B.: dit veronderstelt een goede koppeling tussen DMS en 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). V43 Kantoorautomatisering Beschrijf de mogelijkheden voor wat betreft koppeling met kantoorautomatisering (KA) en beschrijf mogelijke koppelingen met Office applicaties (bijvoorbeeld MS Word, OpenOffice Calc, etc.), bijvoorbeeld om een document als bijlage bij een zaak in het DMS te zetten, om bij de creatie van een document verplicht metadata in te voeren of om (Word-)documenten rechtstreeks in het DMS op te slaan. Beschrijf wat de mogelijkheden zijn m.b.t. documentgeneratie, het gebruik van documentsjablonen en het invoegen van in het midoffice geregistreerde gegevens in een document (zoals een ingescande digitale handtekening en adresgegevens in een Word document). Beschrijf hier tevens de mogelijkheden v.w.b. integratie met zogenaamde huisstijl programma s zoals SmartDocs of MIT Office. Geef hier ook een opsomming van ondersteunde versies (OpenOffice 2.0, MS Office 2003, 2007, etc.) en gebruikte technieken (macro s, API s, etc.). 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. Europese aanbesteding , 28 maart

72 NB: de beoordeling vindt plaats op basis van de relevantie (van de Office versies, de templates, etc.) voor gemeenten. V44 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 (Bestuurlijk Informatie Systeem). 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 inter- en 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. Beschrijf hier tevens de relatie met een Raadsinformatiesysteem, zie ook V Overig V45 Additionele functionaliteiten klantcontactcentrum 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. 5.5 Vragen Midoffice Suite: broker en technische architectuur Broker V46 * 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 Europese aanbesteding , 28 maart

73 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. Bespreek hier tevens het gebruik van business rules. 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 import- en exportfunctionaliteit, bijbehorende bestandsformaten en dergelijke). V47 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). V48 * 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), alsmede op welke wijze monitoring (logging, signalering en dergelijke) plaatsvindt bijvoorbeeld met betrekking tot dreigende overbelasting.. Beschrijf bovendien in hoeverre webservice standaarden zoals WS-I, SOAP, WSDL en UDDI, maar ook WS- Addressing, WS-Security, WS-Reliable Messaging en dergelijke worden ondersteund. Geef tenslotte aan hoe de broker om gaat met storingen. Denk hier aan herstelprocedures, backup&restore (incl. de mate waarin verlies van lopende processen, berichten, bestanden, etc. tegen wordt gaan, bijv. middels logging), bewaren van de integriteit, etc Datadistributie V49 Datadistributie gegevensinrichting Geef aan of, en zo ja hoe, het geoffreerde systeem ondersteuning biedt voor zogeheten datadistributie: het distribueren van (authentieke en andere) gegevens tussen verschillende backoffice applicaties (zoals persoonsgegevens uit het GBA, maar ook gegevens over gebouwen en percelen uit andere authentieke bronsystemen) ten behoeve van het (in)voeren van authentieke basisregistraties. Denk hierbij aan objecttypen zoals Personen (natuurlijk en niet natuurlijk; binnen/buiten gemeente; binnen/buiten Nederland), Adressen, Bedrijven, Gebouwen, Percelen, kaartlagen en dergelijke, maar bijvoorbeeld ook aan publiekrechtelijke beperkingen in het kader van de WKPB Europese aanbesteding , 28 maart

74 Beschrijf, indien van toepassing, de mogelijkheden dienaangaande. Denk hierbij onder meer aan de rol en inrichting van broker, gegevensmagazijn, (synchronisatie)adapters, etc., alsmede aan het gebruik van relevante (open) standaarden (zoals StUF-1/2) en dergelijke. Beschrijf de beoogde inrichting van uw datadistributiesysteem, indien nodig inclusief een model per onderwerp. Betrek hierbij ook externe gegevensbronnen zoals Kadaster, LRD, etc. Geef tevens uw visie op datadistributie zoals u dat in de nabije toekomst ziet en denkt op te lossen. V50 Interne datadistributieproces Beschrijf de functionaliteiten die uw datadistributie-oplossing biedt voor binnengemeentelijke datadistributie. Denk ondermeer aan nieuwe, verwijderde, aangepaste, en gecorrigeerde gegevens, inclusief terugmelding bij een weigering of fout. Beschrijf wat er gebeurt bij overlap, afwijking per bron etc. Beschrijf hierbij de mogelijkheden en granulariteit voor wat betreft autorisatie en privacy. Denk hier bijvoorbeeld aan granulariteit van rechten bij afname, verwijderen, muteren, corrigeren, etc. Beschrijf of en welke workflow mogelijk is bij afwijkende situaties. Geef aan of het mogelijk is inzicht te verschaffen in gegevenskwaliteit en in gebruik en beschrijf hoe u hier rekening houdt met bronnen met verschillende kwaliteiten, prioriteiten, etc. Beschrijf de procesmogelijkheden omtrent datadistributie. Denk hier aan rechten en abonneerregels (zoals nieuwe inwoners > 16jaar ) tot op elementniveau, mogelijkheden rondom translatie en transformatie, etc. Geef bij beantwoording van deze vraag aan voor welke objecttypen de oplossing is te gebruiken. Sommige gemeenten beschikken reeds over een datadistributie voorziening in de vorm van Centric DDS4all of PinkRoccade BRS. Geef aan hoe de Midoffice Suite afnemer (zoals het gegevensmagazijn) en aanbieder (zoals het zakenmagazijn en eventuele generieke applicaties) kan zijn van gegevens ten behoeve van dergelijke voorzieningen. V51 Externe datadistributieproces Beschrijf de functionaliteiten die uw datadistributie-oplossing biedt voor buitengemeentelijke datadistributie in combinatie met binnengemeentelijke afnemers. Denk ondermeer aan Basisregistraties, het GBA-netwerk (LRD, gebruik van een VOA, etc.), de KvK, etc. maar ook energiebedrijven, de Belastingdienst, etc. Beschrijf hoe u hier rekening houdt met bronnen met verschillende kwaliteiten, prioriteiten, etc. Beschrijf de procesmogelijkheden omtrent datadistributie, zoals bij nieuwe, verwijderde, aangepaste, en gecorrigeerde gegevens, inclusief terugmelding bij een weigering of fout. Beschrijf wat er gebeurt bij overlap, afwijking per bron etc., inclusief terugmelding naar de externe partijen. Geef bij beantwoording van deze vraag aan voor welke objecttypen de oplossing is te gebruiken, houd tenminste rekening met het objecttype Bedrijven. Europese aanbesteding , 28 maart

75 5.5.3 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). V52 * 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, parametrisering en dergelijke), inclusief een beschrijving met welke geoffreerde applicatie(s) zij koppelen. V53 * 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.7). 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, parametrisering 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 afschrift GBA) 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.3), op basis van de relevantie van de adapters per Gemeente. V54 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.7). Geef 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,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, Europese aanbesteding , 28 maart

76 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 afschriften GBA) 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.3), op basis van de relevantie van de adapters per Gemeente. V55 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.7). 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 afschriften GBA) 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.3), op basis van de relevantie van de adapters per Gemeente. V56 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. V57 Koppeling met 3P datadistributiesysteem Beschrijf de mogelijkheden van de geoffreerde applicatie(s) om te kunnen koppelen met 3P datadistributievoorzieningen, zoals Centric DDS4all en PinkRoccade BRS. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V58 Koppeling met 3P webintake Geef aan of en hoe u kunt koppelen met externe webintake systemen, zoals de e-formulierenmachine ( en het Digitaal Bouwloket ( Betrek hierbij tenminste de Europese aanbesteding , 28 maart

77 verhouding met de PDC, het overnemen van procesgegevens, de mogelijkheden voor wat betreft pre-fill, de ontvangst van gegevens, etc. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V59 Koppeling met 3P 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 front- en 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. 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.4. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.4 genoemde) PDC s kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V60 Koppeling met 3P 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 front- en 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, 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). Europese aanbesteding , 28 maart

78 Zie voor de CMS en van de verschillende Gemeenten bijlage 8.4. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.4 genoemde) CMS en kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V61 Koppeling met geo-informatie systemen Geef aan hoe u een koppeling realiseert met een bij een Gemeente reeds aanwezig 3P geo-informatiesysteem (GIS) servers en clients. Beschrijf hierbij in hoeverre een 3P GIS gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen front- en 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, backoffice medewerkers, beheerders, ontwikkelaars en dergelijke en geef aan welke gegevens, processen, 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, inclusief pointers van Zakenmagazijn naar GIS. Zie voor de GIS applicaties van de verschillende Gemeenten bijlagen 8.2 en 8.4. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.2 en 8.4 genoemde) GIS applicaties kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V62 * Koppeling met 3P 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 front- en midoffice applicaties. Bespreek hier tevens het koppelen met producten zoals MS SharePoint, Lotus Notes of Novell GroupWise als samenwerkinginstrument ten behoeve van bijvoorbeeld het delen van documenten voor permanente (zoals afdelingen) en/of tijdelijke structuren (zoals projecten). Beschrijf hierbij tenminste de functionaliteiten van de betreffende koppeling, inclusief autorisatiestructuren op verschillende niveaus (bijvoorbeeld map, dossier, document en dergelijke). Beschrijf de technische en functionele eigenschappen van de adapters die integratie Europese aanbesteding , 28 maart

79 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 (wel/niet via de broker, directe / indirecte databasekoppeling, API, URL, webservice, file en dergelijke). Beschrijf bij de ondersteunde functionaliteit ondermeer mogelijkheden zoals checkin/checkout en workflow. Maak in uw antwoord onderscheid tussen functionaliteit voor klanten, FO/KCCmedewerkers, overige 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). Maak hierbij tevens onderscheid tussen de uiteindelijke archivering van documenten (records management) en dossiers en het gebruik van ongestructureerde data tijdens het proces (document management). Zie voor de DMS en van de verschillende gemeenten bijlage 8.4. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.4 genoemde) DMS en kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V63 Koppeling met 3P 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 front- en 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, 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 identity management tools van de verschillende Gemeenten bijlage 8.2. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.2 genoemde) identity management tools kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V64 Koppeling met 3P relatiebeheer Geef aan hoe u een koppeling realiseert met een bij een Gemeente reeds aanwezig 3P Europese aanbesteding , 28 maart

80 relatiebeheer (CRM) applicatie. Beschrijf hierbij in hoeverre een 3P CRM applicatie gekoppeld kan worden met de geoffreerde applicatie(s) en maak hierbij, indien van toepassing, onderscheid tussen front- en 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, overige 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.4. Geef ten slotte aan of, en zo ja hoe, u met eventuele andere (niet in bijlage 8.4 genoemde) CRM applicaties kunt integreren en geef aan welke dit zijn. NB beoordeling vindt plaats, mede gezien de reeds aanwezige applicatiearchitectuur (zie bijlagen), op basis van de relevantie van de adapters per Gemeente. V65 * 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.7). 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 ook aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen en of deze koppeling via de broker, gegevens- en / of zakenmagazijnen gaat, of dat er direct aan de desbetreffende applicatie is gekoppeld. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor afschriften GBA) 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 bijlagen), op basis van de relevantie van de adapters per Gemeente. V66 Overige adapters (synchronisatie en status / datadistributie) Geef een lijst van overige synchronisatie- en statusadapters naar (gemeente)specifieke applicaties (voor zover deze geen betrekking hebben op de top-7 producten zoals genoemd in bijlage 8.7). Geef hierbij steeds aan met welke geoffreerde applicatie(s) de betreffende adapters koppelen, inclusief de ondersteunde versies van de betreffende applicaties, de gebruikte technieken en de functionaliteiten van de betreffende adapters. Denk hierbij met name aan database views, technieken als Oracle streaming, het Europese aanbesteding , 28 maart

81 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 welk onderdeel van de Midoffice Suite dit wordt gedaan, zoals de broker of een separate datadistributie applicatie. Geef aan in hoeverre de betreffende adapters productspecifiek zijn (zoals alleen voor afschriften GBA) 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 bijlagen), op basis van de relevantie van de adapters per Gemeente. V67 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 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. V68 * 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. 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. Europese aanbesteding , 28 maart

82 NB: een zo browser- en platformonafhankelijk mogelijk gedrag met eventueel daarnaast naar keuze een thick client, heeft de voorkeur. Geef per onderdeel van de Midoffice Suite aan of gebruik van Citrix, Terminal Server, etc. binnen de gemeente beperkingen geeft, en zo ja wat deze beperkingen zijn bij welke versie van de genoemde producten. Geef hierbij tevens aan welke beperkingen er zijn indien de medewerker zonder beheerderrechten werkt in Windows. Geef ook aan welke beperkingen er zijn voor het gebruik van Firefox voor de klant en voor de medewerker. Geef aan of, en zo ja welke, beperkingen in functionaliteiten en/of aandachtspunten er zijn indien de website volgens de Webrichtlijnen van overheid.nl wordt aangeboden (voorkeur is automatische en volledige ondersteuning van het voldoen aan de Webrichtlijnen voor de klant, zoals automatische generatie van een Webrichtlijnen versie van een formulier). Geef bijvoorbeeld ook het resultaat van de (geautomatiseerde) check van de Webrichtlijnen van overheid.nl van een bestaande site. V69 Clientside architectuur: power users Geef aan welke browsers en andere clientside technologieën (zoals een fat client ) voor de overige rollen - zoals backoffice medewerker, 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, geef ook aan of er enige beperkingen bestaan bij gebruik van Citrix, Terminal Services, etc. Denk hierbij onder meer aan restricties inzake resolutie, WYSIWYG-editing bij het ontwerpen van formulieren en processen, scherm- en fontgrootte, bekende compatibiliteitsproblemen, etc. V70 * 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. Geef voor elke applicatie resp. elk component aan welke ondersteunde platforms het heeft (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 per applicatie resp. component aan van welke technieken er gebruik wordt gemaakt, zoals voor wat betreft componentmodel (.Net, Java en dergelijke), programmeer- en scripttalen en dergelijke. Indien u verschillende typen operating systemen, databases en middleware nodig heeft, geef aan waarom u dit gedaan heeft en of ook kan worden volstaan met één type operating systeem, database en middleware voor alle applicaties. Europese aanbesteding , 28 maart

83 Beschrijf de mate waarin de Ontwikkel- Test-, Acceptatie- en Productieomgevingen (OTAP) samenhangen dan wel gescheiden zijn (zoals gescheiden databases) en geef 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 mede op basis van reeds aanwezige kennis, ervaring en langlopende contracten met betrekking tot platforms, componentmodellen en applicaties bij de Gemeenten. V71 * Beveiliging Geef aan hoe door de gemeenten gezorgd kan worden voor een adequate beveiliging van zowel front-, mid- als backoffice, zowel per component als in samenhang. Beschrijf de mogelijkheden en beperkingen met betrekking tot beveiliging. Betrek hierbij bijvoorbeeld de Code voor Informatiebeveiliging. Denk hierbij aan databeveiliging (van ingevulde gegevens), communicatiebeveiliging (zoals HTTPS/SSL tussen onderdelen en het gebruik van standaarden zoals WS Security, SAML2 en dergelijke), de betrouwbaarheid en onweerlegbaarheid van online transacties en gegevensintegriteit en vertrouwelijkheid (inclusief encryptie en onweerlegbaarheid), netwerkbeveiliging (zoals de plaatsing van firewalls), het escapen van systeemcommando s en SQL-code, en dergelijke. Geef aan hoe de gegevensintegriteit wordt gewaarborgd van gegevens in en tussen componenten van de Midoffice Suite. 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 en CMS), KCC (gegevens- en zakenmagazijn), broker en backoffices mogelijk is, inclusief functiescheiding en de plaatsing van componenten in gescheiden netwerken zoals een DMZ en scheiding van ontwikkeling/ test/ acceptatie/ productie. Geef tevens aan hoe rechten en rollen worden gedefinieerd over verschillende systemen heen. Bespreek daarbij het gebruik en beheer specifieke bevoegdheden, alsmede het beoordelen van toegangsrechten en toegangsbeveiliging van / naar deelnetwerken (zoals het beperken van toegang tot de beheerderinterfaces). Geef ten slotte aan hoe door de gemeenten gezorgd kan worden voor een adequate beveiliging in front- en midoffice zodat voldaan wordt aan de verschillende relevante wet- en regelgevingen zoals WBP, Archiefwet en dergelijke. Denk hierbij onder meer aan ReMANO, DSP s en de zogeheten basis selectielijst (bijvoorbeeld van de VNG). Geef hier bijvoorbeeld aan welke certificaten zoals dat van Hackersafe u heeft, per module of bij voorkeur voor de gehele suite. Beschrijf de vastlegging van activiteiten en gebeurtenissen (incl. toegang tot de systemen) in auditlogboeken, zowel bij regulier gebruik als bij beheeractiviteiten en maak hierbij, indien relevant, een onderscheid tussen de verschillende componenten van de Midoffice Suite. Beschrijf tevens de mogelijkheden ten aanzien van signalering en logging (incl. audit trails) bij misbruik en maak hierbij, indien relevant, een onderscheid tussen de verschillende componenten van de Midoffice Suite. Europese aanbesteding , 28 maart

84 V72 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 150 ingelogde klanten (die allen een formulier aan het invullen zijn, inzage hebben in hun gegevens en dergelijke) en 100 FO/KCC-medewerkers. Geef daarnaast aan of aanvullend 300 medewerkers in het backoffice als concurrent users het aangeboden DMS met een acceptabele performance kunnen bedienen, inclusief integratie met MS Word etc. (zoals invulling van adresgegevens in een sjabloon). Geef in dit kader ook uw definitie van concurrent users. 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 de (technische) maxima van aantallen openstaande c.q. afgesloten objecten, processen, formulieren en dossiers, de maximale omvang van attachments en dergelijke. Maak indien nodig onderscheid tussen de verschillende componenten van de Midoffice Suite, zoals bijvoorbeeld (indien van toepassing) verschillende metrieken voor broker en datadistributie. Geef een in uw ogen meest adequate schatting van het aantal concurrent users waarmee, op basis van de in paragraaf 1.3 genoemde inwonertallen, rekening gehouden dient te worden en beschrijf of, en zo ja hoe, de aangeboden applicatie(s) hierin voorzien. Geeft een indicatie, op basis van 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. V73 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% Overig V74 Additionele functionaliteiten broker en technische architectuur Hier kunt u additionele (hierboven niet genoemde) in het kader van deze paragraaf 5.5 relevante functionaliteiten van de aangeboden applicatie(s) beschrijven. Europese aanbesteding , 28 maart

85 5.6 Vragen Midoffice Suite: gebruiksgemak en beheer Gebruiksgemak De vragen in deze paragraaf 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. V75 * 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). V76 * 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 (ctrlfuncties, 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). V77 Gebruiksgemak en toegankelijkheid: overige medewerkers Beschrijf welke faciliteiten er beschikbaar zijn voor gebruik door, en ondersteuning daarbij van, de overige medewerkers (zoals het DMS). Geef hier ter illustratie een overzicht van de acties die een 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 (ctrlfuncties, 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 Europese aanbesteding , 28 maart

86 Suite waar medewerker mee te maken hebben, zoals het invullen van een formulier namens een klant en andere frontoffice taken, alsmede statusvolging en andere taken (inclusief CRM, DMS en WfM). V78 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. Indien gebruik wordt gemaakt van fat client technologie, zoals Win32 of specifieke browser plug-ins, geef aan hoe deze gedistribueerd worden naar de client- PC s. Denk hierbij aan Landesk, MS SMS, etc. Bespreek hier tevens in hoeverre de ITIL, BiSL en / of ASL raamwerken gebruikt kunnen worden. V79 Gebruiksgemak en toegankelijkheid: formulier- en 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 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. V80 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. V81 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 Beheer De vragen in deze paragraaf 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. Europese aanbesteding , 28 maart

87 V82 * 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, per component en voor de gehele suite (incl. communicatie via de broker). 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. 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 afschriften GBA), waarbij de integriteit en echtheid van wordt gewaarborgd met een echtheidskeurmerk (zoals ten behoeve van scholen, woningcorporaties en dergelijke). NB: bij beoordeling wordt de aangeboden Midoffice Suite als één geheel gezien, inclusief autorisatie over alle applicaties. V83 * 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 (incl. remote beheer), scripting, koppelingen met 1P en 3P beheer-, rapportage- en analysetools, backup- en restore, en dergelijke. NB: dit betreft de kracht en breedte van de hulpmiddelen, niet het gebruiksgemak ervan. Europese aanbesteding , 28 maart

88 Geef ten slotte aan hoeveel FTE een gemeente met een inwonertal tussen de en en hoeveel FTE een gemeente met een inwonertal tussen de en inwoners 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 mede op basis van reeds aanwezige kennis, ervaring en langlopende contracten met betrekking tot platforms, componentmodellen en applicaties bij de Gemeenten 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. V84 Managementinformatie Beschrijf de mogelijkheden voor wat betreft (management)rapportages voor FO/KCC functies alsook voor de overige onderdelen van de Midoffice Suite 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. Onderscheid bij de beantwoording van deze vraag standaardrapportages en complexe adhoc 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 realtime 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 op het gebied van managementinformatie (zoals Cognos, Crystal Report en dergelijke), ETL (zoals PowerCenter, Business Object en dergelijk) etc. kunnen worden gebruikt, onder vermelding van versienummers en dergelijke. Beschrijf de eventueel reeds beschikbare standaardrapportages via deze applicaties. Beschrijf ten slotte de mate waarin, en de voorwaarden waaronder, gemeenten inzicht krijgen in de datamodellen van alle onderdelen van de Midoffice Suite (ten behoeve van read-only toegang voor het komen tot managementinformatie). Europese aanbesteding , 28 maart

89 5.6.4 Integratie V85 V86 Regie Indien er bij de Inschrijver sprake is van een Hoofd- en een Onderaannemer of van een Combinatie van Aannemers, beschrijf dan de regie en samenhang tussen de verschillende Aannemers en Onderaannemers. * 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. Beschrijf hier tevens hoe de verschillende systemen onderling worden gekoppeld. Geef bijvoorbeeld aan of een koppeling tussen CMS en DMS via de broker wordt gedaan, of dat de verschillende onderdelen direct met elkaar zijn gekoppeld. V87 * 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. V88 * 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 document- en case management) en broker workflow (BPM / procesorkestratie) door dezelfde componenten / tools / interfaces kan worden gerealiseerd. V89 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 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. V90 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 Europese aanbesteding , 28 maart

90 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/KCCmedewerker - 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). V91 Content integratie Beschrijf de integratie tussen de verschillende onderdelen van de Midoffice Suite (frontoffice, klantcontactcentrum en broker) voor wat betreft content. Denk hierbij aan bijvoorbeeld enkelvoudig beheer in CMS of PDC en meervoudig gebruik van content in CMS, DMS, webintake systeem, KCC (bijv. een FAQ), etc. Bespreek hier ook de verhouding tussen Raadsinformatie Systeem en Bestuurlijk Informatie Systeem. Europese aanbesteding , 28 maart

91 5.7 Eisen en vragen Initiële implementatie 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. Formulieren, processen, inrichting, etc. zullen zoveel mogelijk generiek zijn, maar zullen voor elke Gemeente waarschijnlijk afwijken. Onderstaande is een globale schets, welk later per Gemeente wordt ingevuld. Er wordt dus níet een volledig identieke implementatiebij elke Gemeente aanbesteedt, op het geheel noch op onderdelen. Niet alle Gemeenten zullen de volledige Midoffice Suite afnemen. Elk van de Gemeenten heeft 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 - Migratie van DMS objecten 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) 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 (drie 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 front- en midoffice De front- en 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), inclusief (voor zover relevant) CMS, CRM, DMS, broker, datadistributie, etc. 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 Europese aanbesteding , 28 maart

92 gegevensmagazijn, één zakenmagazijn en één centraal aangestuurde horizontale workflow. Configuratie van software ten behoeve van de integratie tussen front- en midoffice dient in deze fase plaats te vinden. Daarnaast moeten eventuele ondersteunende applicaties zoals een webserver, applicatieserver en/of andere applicaties werkend zijn geïnstalleerd en moet een ontwikkel-, test- en acceptatie omgeving zijn ingericht. Basisimplementatie front- en midoffice Na de installatie vindt de basisimplementatie van front- en midoffice plaats. Deze bestaat enerzijds uit de technische configuratie, het inrichten van gebruikers, rechten en rollen en dergelijke, alsmede de integratie tussen front- en midoffice. Ook de basisinrichting van gegevens, processen en functioneel en technisch beheer behoort tot de basisimplementatie. De basisinrichting van gegevens heeft betrekking op het gegevens- en zakenmagazijn en het aansluiten van de product-dienstencatalogus (PDC) en eventuele kennisbomen. Bij de procesinrichting verdienen de basisstatussen, notificaties 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. Implementatie en inrichting van het Web Content Management (incl. conversie van de huidige sites) is expliciet géén onderdeel van de basisimplementatie, doch valt onder Meerwerk. Implementatie van het DMS valt wel onder de basisimplementatie, voor zover dit het midoffice de Top-7 producten betreft. Een organisatiebrede inrichting maakt echter géén onderdeel uit van de basisimplementatie: dat laatste is meerwerk. 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 afschrift GBA - Aanvragen verhuizing (binnengemeentelijke én buitengemeentelijk) - Indienen melding openbaar gebied - Indienen generiek bezwaarschrift - Aanvragen evenementenvergunning - Aanvragen gecombineerde BKS-vergunning o Lichte bouwvergunning o Kapvergunning o Sloopvergunning Europese aanbesteding , 28 maart

93 - Intern: in- en uitdiensttreding - Bijlage 8.7 bevat een globale beschrijving van de betreffende producten, terwijl in bijlage 8.3 per product is aangegeven welke backoffice applicaties bij de verschillende Gemeenten aan de betreffende producten zijn gerelateerd. Bij inrichting van de FO- en KCC-componenten als webintake, product-dienstencatalogus, zakenmagazijn, gegevensmagazijn en document management tbv. Top-7 behoort ook de eventuele conversie van formulieren, productbeschrijvingen, inrichting gegevensmagazijn, etc. uit bestaande en te vervangen systemen. Zie ook bijlagen 8.2 tot en met 8.4. Per product dient onder meer aandacht te worden besteed aan het elektronische formulier, de inrichting van het gegevens- en zakenmagazijn, de communicatie met relevante front- en backoffice applicaties en andere systemen, de inrichting van statussen en de mogelijkheid om zogenaamde backoffice-loze producten of generieke applicaties te ontwikkelen en gebruiken in een dik midoffice. 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. Een deel van de Top-7 producten zal dun worden ingericht. Dit betekent dat de afhandeling van een aanvraag, melding, etc. in een bestaand backoffice zal geschieden. De midoffice inrichting betreft dan bijvoorbeeld formulieren inclusief kaartje en prefill en validatie vanuit gegevensmagazijn, een beschrijving in het PDC, adapters naar de desbetreffende backoffice(s), koppeling met DMS (bijlagen bij een formulier), routering van berichten via de broker, weergave van statussen middels een zakenmagazijn, etc. Andere producten zullen dik worden ingericht. Hier wordt dus de volledige afhandeling in het midoffice gedaan en is er geen backoffice om mee te koppelen. De keuze van dikke of dunne inrichting van een product wordt per Gemeente gemaakt en zal soms pas worden gemaakt indien de mogelijkheden van het geoffreerde midoffice systeem bekend zijn. 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 hebben de uitdrukkelijke intentie om voor de dunne producten uit de Initiële implementatie naast synchronisatie- en statuskoppelingen indien van toepassing ook transactiekoppelingen te realiseren. Volgens het fasemodel elektronische dienstverlening (zie figuur 5.3) heeft dergelijke transactie integratie betrekking op fase 3. Overigens lenen niet alle gemeentelijke producten zich daadwerkelijk voor elektronische levering (fase 4). Fase Publicatie Intake Verwerking Levering Fase 0 Papieren formulier Handmatig (papier) Handmatig (papier) Handmatig (papier) Fase 1 PDF-/Wordformulier Handmatig (papier) Handmatig (papier) Handmatig (papier) Fase 2 Web-/E-formulier Elektronisch Handmatig (papier) Handmatig (papier) Fase 3 Web-/E-formulier Elektronisch Elektronisch Handmatig (papier) Fase 4 Web-/E-formulier Elektronisch Elektronisch Elektronisch Europese aanbesteding , 28 maart

94 Figuur 5.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 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). Migratie Tenslotte worden, indien relevant, eventuele bestaande objecten uit het bestaande en te vervangen DMS gemigreerd naar het DMS. Zie ook bijlagen 8.2 tot en met 8.4. 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/KCCmedewerkers, 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 met waar mogelijk generieke maar waar nodig gemeentespecifieke formulieren, processen, adapters, inrichting van magazijnen, etc. - Het voldoen aan alle functionele Eisen is expliciet aangetoond. - Een volledig autorisatiemodel (rechten en rollen) is actief overeenkomstig de situatie bij de individuele Gemeenten. - 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.2 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). Initiële implementatie van de componenten geldt alleen voor zover het de inrichting van de Top- 7 producten in het midoffice betreft. Bijvoorbeeld een gemeentebrede inrichting van datadistributie, gemeentebrede archivering middels het DMS of inrichting van een CMS tbv. de gemeentelijke websites vallen onder meerwerk. Europese aanbesteding , 28 maart

95 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 formulieren invullen. Vervolgens kunnen ze (in ieder geval via het web en via ) 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. - Klanten kunnen in formulieren gebruik maken van kaartjes om de locatie van een zaak aan te geven. - Informatie in een GIS en in het zakenmagazijn kunnen naar de klant ontsloten worden via een gepersonaliseerd en interactief kaartje. - Het CMS is geïnstalleerd. Midoffice - De broker is actief, inclusief datadistributie vwb. de Top-7 producten. Alle gekoppelde systemen kunnen informatie overdragen. - Er is één gegevensmagazijn gerealiseerd. Hieruit wordt in ieder geval de informatie gehaald ten behoeve van prefill, inrichting van het gegevensmagazijn is dus conform de attributen op de formulieren. - 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, statusupdates van achterliggende applicaties. Ook is contactregistratie mogelijk. - FO/KCC- en andere 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. DMS - Het DMS is geïnstalleerd, geconfigureerd en geïntegreerd met de Midoffice Suite. Europese aanbesteding , 28 maart

96 - Er is een document repository en een DSP ingericht, conform de Archiefwet en de ReMANO specificaties. Afhankelijk van de rechten kunnen medewerkers documenten inzien, bewerken, metadata wijzigen, verwijderen, etc. - Alle documenten uit een eventueel reeds aanwezig DMS zijn geconverteerd naar het nieuwe DMS, alsook de hieraan gerelateerde metadata. - De autorisatiestructuur (rollen en rechten) voor medewerkers, burgers en bedrijven is volledig ingericht. - Postregistratie van ingaande en uitgaande post (papier en ) 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 (voor zover relevant) voor alle onderdelen van de Midoffice Suite. - 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 door medewerkers inzien van status én het doorgeven van statusupdates in het Midoffice is mogelijk. - Het is mogelijk voor FO/KCC-, DIV- en andere 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. Inrichting is steeds gemeentespecifiek. De beschreven formulieren, processen, etc. dienen als voorbeeld. 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/KCC-medewerkers, 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. Europese aanbesteding , 28 maart

97 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 en functioneel beheerders, en de technisch beheerders en andere belanghebbenden van de gemeente zodanig te trainen en van documentatie te voorzien dat de gemeenten zelfstandig het complete front- en midoffice (inclusief eventuele integratiemodulen) kunnen gebruiken, functioneel en technisch kunnen beheren en kunnen onderhouden. E25 Documentatie Alle eindgebruikerdocumentatie dient volledig in het Nederlands te zijn gesteld. NB: dit betreft dus niet documentatie met als enige doelgroep programmeurs of technisch beheerders, wat eventueel ook in het Engels mag 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 Vragen implementatie V92 * 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. Geef hier ook aan hoe u de initiële implementatie inhoudelijk wilt aanpakken om de gevraagde functionaliteiten te realiseren en geef aan welke (kritische) succesfactoren u hier ziet. Maak hier onderscheid tussen organisatorische, functionele en technische aspecten. Geef hierbij ook aan welke organisatorische, functionele en technische taken en verantwoordelijkheden een Gemeente hier heeft. Europese aanbesteding , 28 maart

98 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 (verandermanagement). Geef zowel in het algemeen als per product (zie ook bijlage 8.7) 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. Sommige Gemeenten hebben de ambitie om het DMS (op termijn) Gemeentebreed in te gaan zetten voor document- en recordmanagement (dwz digitaal archief conform de Archiefwet) zoals dossiervorming, postregistratie (inclusief ), ondersteuning van het DSP en dergelijke. Geef in het Plan van Aanpak derhalve ook op welke wijze u deze Gemeentebrede ambitie met het geoffreerde DMS kan realiseren. N.B. één gezamenlijk Plan van Aanpak heeft hier de voorkeur, dus niet een Plan van Aanpak per (onder)aannemer. De beoordeling vindt plaats op fit met de Gemeenten, haalbaarheid, volledigheid, etc. V93 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 conversie van eventueel reeds aanwezige vormen van elektronische dienstverlening (gemeentelijke producten) naar de geoffreerde oplossing denkt aan te pakken (formulieren, processen. etc. in bestaande midofficesystemen). Geef bij de beantwoording van deze vraag zomogelijk een zo gedetailleerd mogelijke planning, inclusief relevante milestones. Bespreek tenminste de migratie van een huidig DMS en van een huidige website / CMS. V94 * 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, vijf zes of alle zeven Gemeente(n), waarbij de Initiële implementaties bij drie Gemeenten deels parallel Europese aanbesteding , 28 maart

99 worden uitgevoerd. Specificeer bij elk scenario de te verwachten personele inzet van zowel uw kant als van de kant van de Gemeente (specificeer de rollen en de kennis). V95 * 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 zeven Gemeente(n), waarbij de Initiële implementaties bij twee of meer Gemeenten deels parallel worden uitgevoerd. V96 * 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 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 geïmplementeerd kunnen worden. V97 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 front- en 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 de Gemeenten en niet bij de Offerte begrepen zijn op basis van uw beantwoording van het Programma van Eisen. NB: de beoordeling vindt plaats op transparantie. V98 * Kostenstructuur Beschrijf de kostenstructuur van de geoffreerde applicatie(s) en eventuele extra modules. Maak hierbij onderscheid tussen de front- en midoffice onderdelen. Europese aanbesteding , 28 maart

100 Geef aan welke kosten eenmalig zijn, en wat de jaarlijkse onderhoudskosten (zoals gedefinieerd in de overeenkomst) 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 third-party, add-on modules en eventueel maatwerk, indien deze zijn genoemd bij de beantwoording van het Programma van Eisen. Het kostenschema moet op basis van Max-price zijn en gedimensioneerd zijn voor het huidige en toekomstige interne en externe gebruik. Geef hierbij aan hoe omgegaan wordt met optioneel en verplicht meerwerk en met minderwerk (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, vijf, zes, etc. Gemeenten, alsmede door eventuele additionele Gemeenten. Bespreek hier ook eventuele kickbacks. NB: de beoordeling vindt plaats op transparantie. Hier is echter wel de voorkeur voor het onderscheiden van de mogelijkheden voor ASP en voor lokale installatie. De prijs wordt gevraagd in hoofdstuk 6. V99 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 65% elektronische dienstverlening in het kader van het Programma Andere Overheid, zie ook paragraaf 8.8), inclusief de kosten voor training, support, onderhoud en dergelijke. Geef aan wat de gemiddelde, minimale en maximale kosten zijn en geef enkele praktijkvoorbeelden. De Gemeenten schatten 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 de 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. V100 * Roadmap en visie Beschrijf uw visie op gemeentelijke elektronische dienstverlening en hoe dit zich verhoudt tot het geschetste front- en 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), Europese aanbesteding , 28 maart

101 Digitaal Klant Dossier (DKD), Samenwerkende Catalogi en de Persoonlijke Internet Pagina (PIP), alsmede ontwikkelingen rondom de omgevingsvergunning, WMO, de ICTU E-formulierenmachine en dergelijke, alsmede op ontwikkelingen rondom en het gebruik van 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 front- en midoffice / klantcontactcentrum concept. Ga hierbij ook in op toekomstige ontwikkelingen bij gemeenten, bijvoorbeeld zoals beschreven in het rapport van de Commissie Gemeentelijke Dienstverlening ( Commissie Jorritsma ); geef bijvoorbeeld aan wat over drie jaar de situatie bij gemeenten zou kunnen zijn en hoe de geoffreerde applicaties in dat beeld passen. Ga hier ook 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 en de mate waarin nieuwe versies worden voorzien van (technische en gebruikers-)documentatie. Geef aan in welke mate de aangeboden applicatie(s) en de bijbehorende ontwikkelaar / leverancier toekomstvast is in termen van product- en 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 en hoe de regie hieromtrent is geregeld. Geef aan wat het beleid is rondom het voor alle typen gebruikers- en ontwikkelaars aanbieden van documentatie van nieuwe versies. V101 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 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). Europese aanbesteding , 28 maart

102 V102 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 (gebruikers, beheerders en medewerkers); geef hierbij bovendien steeds aan of de betreffende documentatie in het Nederlands beschikbaar is. Geef aan hoe u de Service Niveau Overeenkomst denkt in te vullen, waar u paragraaf 8.14 als uitgangspunt kunt nemen. Indien open source, geef aan of, hoe en welke commerciële partijen betrokken zijn bij onderhoud en support en hoe de regie mbt. het onderhoud is geregeld. Europese aanbesteding , 28 maart

103 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. E29 E30 E31 E32 E33 E34 E35 E36 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. Het gebruiksrecht van applicaties is niet gekoppeld aan onderhoudscontracten. 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. Alle geldbedragen in de Offerte zijn inclusief omzetbelasting (BTW), met uitzondering van het antwoord op de eisen E11 en E12. Alle geoffreerde prijzen dienen te zijn gebaseerd op de in het Bestek genoemde specificaties. De in de Offerte genoemde tarieven voor diensten dienen vast en onveranderlijk te zijn tot 1 mei 2008, daarna mogen ze tijdens de duur (en eventuele verlenging) van de overeenkomst slechts eenmaal per jaar gewijzigd worden met maximaal het CBSindexcijfer voor overige dienstverlening. 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). De in de paragraaf van bijlage 8.1 (het prijssjabloon) gevraagde tariefopslagen mogen niet meer dan 150% bedragen. U dient een betalingstermijn van 30 dagen (na factuurdatum) te hanteren, met dien verstande dat facturering plaatsvindt na acceptatie door de klant. V103 Prijs 5 Inschrijver dient de prijs aan te leveren volgens het prijssjabloon in bijlage 8.1. De Gemeenten willen middels dit prijzensjabloon een goed inzicht krijgen in de totale kosten van de aanbieding. Het sjabloon gaat dan ook uit van de totale kosten, d.w.z. alle kosten van de software over 5 jaar, inclusief alle bijbehorende producten en diensten, zoals onderhoud, training, implementatie, maatwerk, minderwerk en meerwerk. Verwacht wordt dat de diensten worden aangeboden op basis van Max-price. Het prijssjabloon bestaat uit de volgende paragrafen: 1) Algemene toelichting 2) Applicaties en componenten 3) Software 4) Maatwerksoftware 5 N.B. deze vraag telt niet mee voor bepaling van de q-score, zoals beschreven in paragraaf Zie ook V98 Europese aanbesteding , 28 maart

104 5) Implementatie 6) Training & Documentatie 7) Verplicht meer- en minderwerk 8) Optioneel meerwerk 9) Tarieven & Opslagen 10) Beheer Totale kosten Geef vervolgens de totale kosten over een periode van 5 jaar en op basis van Max-price voor een standaard Gemeente weer volgens onderstaand model. Sommeer hiertoe de gemiddelde bedragen indien een prijsbereik is aangeduid, en sommeer de Max-price bij diensten. Kosten software (5 jaar) Kosten maatwerksoftware (5 jaar) Kosten Top-7 koppelingen 3 * Kosten Top-7 koppelingen Kosten Initiële implementatie (Max-price) 3 * Kosten Initiële implementatie (Max-price) Kosten training en documentatie (5 jaar) + Totale kosten E37 Inschrijver garandeert dat met de middels het prijssjabloon in bijlage 8.1 aangeboden software (incl. add-ons, maatwerk, etc.) en diensten alle functionaliteit kan worden gerealiseerd, die in de antwoorden op de vragen wordt genoemd. Inschrijver dient hiervoor ook bijlage 8.10: Controlelijst vragen en functionaliteit in te vullen (zie ook toelichting aldaar). Bij het niet aldus aanbieden van (één van) de gevraagde onderdelen van het prijssjabloon zal de prijs van het onderdeel voor het bepalen van de f-score (zie paragraaf 2.5.4) gelijk worden gesteld aan een door het Consortium nog in redelijkheid te bepalen forfaitbedrag. Daarnaast zal het niet geven van een prijs de score van de vragen negatief kunnen beïnvloeden. Geef het derhalve expliciet aan indien een onderdeel kosteloos wordt aangeboden. Europese aanbesteding , 28 maart

105 7 JURIDISCHE VOORWAARDEN Bij dit Bestek is een conceptovereenkomst gevoegd (bijlage 8.12). In dit hoofdstuk worden de eisen en vragen met betrekking tot deze conceptovereenkomst gesteld. E38 In bijlage 8.12 is de Overeenkomst opgenomen. De Overeenkomst bevat de bepalingen die van toepassing zijn op de uitvoering van de opdracht. U dient volledig in te stemmen met de Overeenkomst. Indien u wijzigingen in de bepalingen wenst aan te brengen dan dient u dit aan te geven in de vragenronde (zie paragraaf 2.3.1: Schriftelijke Vragen) en daartoe tekstvoorstellen te doen. De Gemeenten zullen vervolgens bepalen of het betreffende artikel kan worden aangepast, maar is geenszins verplicht wijzigingsvoorstellen over te nemen. Een dergelijke aanpassing zal dan voorts in de Nota van Inlichtingen aan u worden gecommuniceerd. Hierna zijn geen wijzigingen meer mogelijk op de Overeenkomst en de Inschrijver dient de Bijlage dan ook te ondertekenen voor instemming en akkoord. De in de Overeenkomst genoemde bijlagen worden bij Gunning door Partijen in overleg nader vastgesteld. E39 E40 E41 E42 E43 E44 Voor de Proof of Concept gelden de algemene voorwaarden in bijlage 1.1. Inschrijver dient zich akkoord te verklaren met de gestelde voorwaarden. De conceptovereenkomst kan alvorens deze door partijen wordt ondertekend door de Gemeenten 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. Inschrijver dient een door de gemeente goed te keuren versie van een Service Niveau Overeenkomst op te stellen, bevattende het geheel van operationele afspraken op basis waarvan Implementatiepartner het onderhoud uitvoert. Dit op basis van de in Bijlage 1.1 beschreven onderhoudsdiensten. De Inschrijver zal in de Offerte geen algemene voorwaarden opnemen of hiernaar verwijzen. Op deze aanbesteding en de eventueel te sluiten overeenkomsten is het Nederlands recht van toepassing. 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. Europese aanbesteding , 28 maart

106 8 BIJLAGEN 8.1 Prijssjabloon Europese aanbesteding Midoffice Suite Algemene toelichting prijssjabloon Doel De samenwerkende Gemeenten binnen ANDEZ2 willen middels dit prijzensjabloon een gedegen inzicht verkrijgen in de prijsstelling van de diverse Inschrijvers om deze beter te kunnen vergelijken. De totale kosten dienen dan ook alle kosten van de software over 5 jaar te bevatten, inclusief alle bijbehorende producten en diensten, zoals onderhoud 6, training en implementatie. Inhoud Dit prijssjabloon bestaat uit een aantal paragrafen: 1) Algemene toelichting 2) Applicaties en componenten 3) Software 4) Maatwerksoftware 5) Implementatie 6) Training & Documentatie 7) Verplicht meer- en minderwerk 8) Optioneel meerwerk 9) Tarieven & Opslagen 10) Beheer Invulinstructie Om de administratieve lasten voor een Inschrijver beperkt te houden, kan dit prijssjabloon in eerste instantie worden ingevuld op basis van een standaard gemeente van ongeveer inwoners en kan waar aangegeven de prijs worden gegeven in de vorm van een prijsrange met een maximale afwijking van het prijsgemiddelde van maximaal 20% naar boven en naar beneden. Op basis van deze prijsopgave zullen de Gemeenten een prijs bepalen om de f-score te berekenen. Tijdens de PoC zal aan Inschrijvers uit de top-n worden gevraagd om offertes per Gemeente op te stellen en de prijzen nader te specificeren. Deze offertes dienen overeen te komen met de informatie in dit prijssjabloon. Dit prijssjabloon dient vwb de licenties te worden ingevuld op basis van applicaties. In paragraaf dienen de applicaties te worden gespecificeerd. Maatwerksoftware, de zogenaamde externe Midoffice koppelingen en de implementatie mag over applicaties heen worden gespecificeerd, mits precies duidelijk is wat er met de maatwerksoftware wordt bedoeld en waarop deze betrekking heeft. 6 De precieze definitie van onderhoud is te vinden in de overeenkomst die separaat bij het bestek en de prijsbijlage is gevoegd. Europese aanbesteding , 28 maart

107 Met de aangeboden applicaties (inclusief koppelingen, add-ons, maatwerksoftware, etc.) en diensten dient alle functionaliteit die in de antwoorden op de vragen door de Inschrijver wordt genoemd te kunnen worden gerealiseerd. Indien blijkt dat dit niet geval is zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van de ontbrekende onderdelen gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfait-bedrag (zie ook paragraaf van het Bestek). De Inschrijver mag er dus niet vanuit gaan dat bijvoorbeeld bepaalde applicaties reeds bij Gemeenten aanwezig zijn, met uitzondering van operating systemen en database management systemen. Alle geoffreerde prijzen dienen te zijn gebaseerd op de in het Bestek genoemde specificaties (zie E37 in het Bestek). Koppelingen In het Bestek en in dit prijssjabloon onderscheiden we drie soorten koppelingen. 1. De interne midoffice koppelingen. Dit zijn koppelingen tussen applicaties die door de Inschrijver worden aangeboden (1P) als onderdeel van de Midoffice Suite. Het betreft dus applicaties die voorzien in (een aantal) componenten zoals die worden besproken in paragraaf De kosten voor deze koppelingen worden geacht te zijn inbegrepen bij de prijs van de software, zoals gevraagd in paragraaf Deze koppelingen mogen dus niet separaat worden geprijsd. 2. De externe midoffice koppelingen. Dit zijn koppelingen tussen door de Inschrijver aangeboden applicaties en 3P applicaties bij een Gemeente, die weliswaar voorzien in (een aantal) componenten zoals die worden besproken in paragraaf en in die hoedanigheid onderdeel uitmaken van een midoffice, maar die niet in het kader van deze aanbesteding door de Inschrijver aan de Gemeente worden geleverd 8. Deze koppelingen dienen apart te worden geprijsd en worden gevraagd in paragraaf De externe backoffice koppelingen. Dit zijn koppelingen tussen door de Inschrijver aangeboden midoffice applicaties (m.n. de broker) en 3P applicaties in een gemeentelijke backoffice, waarmee moet worden gekoppeld als onderdeel van de Initiële implementatie (van de Top-7) 9. Per applicatie dient een transactie-, synchronisatie- en statuskoppeling te worden geleverd. Deze koppelingen worden geprijsd als onderdeel van het dun inrichten van een gemeentelijk Top-7 product en worden gevraagd in paragraaf Korting en kick-back In 2007 en later zullen mogelijk nog een aantal Gemeenten op basis van dit bestek (met eigen bijlagen) een Midoffice Suite aanbesteden: de vervolg ANDEZ-en. Geef aan welke kortingen (bijvoorbeeld in de vorm van een cumulatieve staffel) dit voor de samenwerkende Gemeenten en de later aansluitende gemeenten oplevert. Besteed in ieder geval aandacht aan éénmalige licentiekosten, jaarlijkse licentiekosten, implementatie, maatwerksoftware, documentatie, etc Bij interne midoffice koppelingen kan bijvoorbeeld worden gedacht aan koppelingen tussen het DMS en het Midoffice, tussen de Frontoffice en het Midoffice, tussen het Frontoffice en het DMS, tussen het Frontoffice en de GIS viewer, naar DigiD en Ogone, tussen het KCC en het Frontoffice, tussen het KCC en het Midoffice, tussen het KCC en het DMS en tussen het Midoffice (broker) en GIS, etc. Bij externe midoffice koppelingen kan bijvoorbeeld worden gedacht aan een koppeling met een 3P DMS of een 3P CMS: producten die deel uitmaken van een midoffice maar reeds bij Gemeente aanwezig zijn en niet worden afgenomen van Inschrijver. Een externe backoffice koppeling uit de Top-7 is bijvoorbeeld de koppeling met PIV4all in het kader van het product Binnengemeentelijke verhuizing. Europese aanbesteding , 28 maart

108 Specificeer tevens de kick-back regeling, m.n. voor maatwerksoftware. Bij een kickbackregeling geniet een Gemeente een terugverdieneffect, wanneer andere gemeenten aansluiten of u de voor de Gemeenten ontwikkelde maatwerksoftware en/of producten, processen en dergelijke vermarkt. Meer- en minderwerk Het minderwerk is het bedrag dat een afnemer minder hoeft te betalen bij het niet afnemen van een bepaalde applicatie(component) ten opzichte van de volledige Midoffice Suite. Het minderwerk voor deze afnemer bestaat dan uit de softwarekosten zoals gespecificeerd in paragraaf en de implementatiekosten voor de betreffende applicatie(s) zoals gespecificeerd in paragraaf Het niet afnemen van een applicatie(component) heeft meestal verplicht meerwerk in de vorm van een koppeling met de 3P applicatie(s) van de Gemeente tot gevolg. Het optionele meerwerk, zoals dat wordt uitgevraagd in paragraaf is optioneel en Inschrijver is derhalve niet verplicht dit aan te bieden. Optioneel meerwerk telt niet mee bij bepaling van de p-, de q- of de f-score zoals beschreven in paragraaf en telt dus ook niet bij bepaling van de Top-1 per Gemeente, de Top-3 per Gemeente of de Top-n. Standaard gemeente In een aantal tabellen wordt gevraagd naar de kosten voor een standaard gemeente van (ongeveer) inwoners. Beschrijf indien van toepassing ook de prijsafhankelijkheid van het aantal inwoners, bijvoorbeeld m.b.v. een formule, zodat de Gemeenten zelf de kosten kan berekenen voor een Gemeente met een ander inwonertal, bijvoorbeeld voor een Gemeente van of inwoners. Prijzen Alle bedragen dienen te zijn vastgesteld in Euro s ( ), inclusief BTW. De diensten worden aangeboden op basis van Max-price (zie paragraaf 1.3). Tarieven dienen inclusief reis- en verblijfskosten te zijn. Europese aanbesteding , 28 maart

109 8.1.2 Applicaties en componenten Dit prijssjabloon dient vwb de licenties te worden ingevuld op basis van applicaties. Een uitzondering hierop is de maatwerksoftware, implementatie en zgn. externe koppelingen. Dit mag over applicaties heen worden gespecificeerd, mits precies duidelijk is wat er met de maatwerksoftware wordt bedoeld en waarop deze betrekking heeft. Inschrijver dient per applicatie aan te geven in welke componenten deze voorziet 10. We onderscheiden de volgende componenten: 1) Webintake (WIS), inclusief Ogone en DigiD) 2) GIS client: viewer (inclusief koppeling met bestaande geo systemen) 3) PDC (inclusief vraaggeleiding en zoeken) 4) CMS 5) Broker (inclusief A2A workflow) 6) Datadistributie 7) DMS/RMA 8) WfM (alleen human workflow, A2P) 9) CRM 10) Gegevensmagazijn (inclusief evt. geo-magazijn) 11) Zakenmagazijn 12) Overig (specificeer) Daarnaast dient Inschrijver per applicatie de interne midoffice koppelingen te specificeren. In paragraaf van dit prijssjabloon staat onder kopje Koppelingen een toelichting op de onderverdeling van koppelingen. Specificeer alle applicaties, componenten en interne midoffice koppelingen volgens onderstaande tabel Applicaties & Componenten. Applicaties & Componenten Applicatie Componenten Interne midoffice Koppelingen Applicatie 1, Naam Applicatie 2, Naam Applicatie Applicaties moeten bij voorkeur komen van één leverancier en op dezelfde technologie zijn gebaseerd. Geef per applicatie (of additionele module) aan of er (door uzelf geleverde) alternatieven zijn (zoals een light versie, enterprise edition, etc). Geef hierbij steeds per alternatief aan of het vervangen van een bepaalde applicatie (of module) door dat betreffende alternatief gevolgen heeft voor de rest van de applicaties, en zo ja welke. 10 Zo kan workflowfunctionaliteit bijvoorbeeld door de applicatie DMS/WfM worden ingevuld. Als de PDC- en zoekfunctionaliteit door het webintake systeem worden ingevuld, ontstaat de applicatie WIS/PDC/zoeken, etc. De applicaties (clusters van componenten) dienen zo volledig mogelijk te worden gespecificeerd. Europese aanbesteding , 28 maart

110 Alternatieve applicaties Applicatie Alternatieven Gevolgen Applicatie 1, Naam Applicatie 2, Naam Applicatie Europese aanbesteding , 28 maart

111 8.1.3 Software De onderstaande tabel Software dient vwb de licenties te worden ingevuld op basis van de applicaties zoals uitgevraagd in paragraaf Indien een bepaald onderdeel niet wordt aangeboden zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van het ontbrekende deel gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfait-bedrag. In paragraaf zijn de zgn. interne midoffice koppelingen beschreven. De prijs voor deze koppelingen dient in de applicaties te zijn inbegrepen en deze koppelingen mogen dus niet apart worden geprijsd 11. Conform het bestek zijn de kosten voor operating systems en database management systemen niet opgenomen in de totaalprijs p zoals gespecificeerd in paragraaf en derhalve hoeven de prijzen niet te worden opgegeven. Let op! Indien bepaalde applicaties worden aangeboden waarvoor onderliggende middleware is vereist dient de middleware wel in het prijssjabloon te worden opgenomen. De kolom Totaal 5 jaar dient het totaal bedrag voor het aangegeven, genummerde, onderdeel te bevatten. Dit bedrag bestaat uit de éénmalige kosten van de software + vijf maal de jaarlijkse kosten van de software. Indien de jaarlijkse kosten niet gelden voor het eerste jaar dan dient dit expliciet te worden aangegeven. Indien de jaarlijkse kosten jaarlijks wijzigen dan dient dit expliciet te worden aangegeven. Indien het onderhoud een percentage is, specificeer dan of dit van de list-prijs is of van de geoffreerde prijs en geef in de betreffende kolommen het bedrag in Euro. Om de licentiekosten vergelijkbaar te maken dient een aantal licenties te worden opgegeven voor de ontwikkel-/test-, acceptatie- en productieservers. Ga uit van een ontwikkel- en testomgeving die d.m.v. virtualisatie op 1 systeem draaien. Om bepaalde eigenschappen van het systeem, zoals loadbalancing op een realistische wijze te kunnen testen, dient de acceptatieomgeving minimaal te bestaan uit twee web-/applicatieservers. Bij de dimensionering van de productieomgeving (aantal servers/cpu) dient te worden uitgegaan van 250 concurrent users, waarbij 250 concurrent users hier gedefinieerd is als een mix van 150 ingelogde klanten (die allen een formulier aan het invullen zijn, inzage hebben in hun gegevens en dergelijke) en 100 FO/KCC-medewerkers. Geef daarnaast de prijs voor een extra aantal van 300 concurrent userlicenties om in het backoffice het aangeboden DMS te bedienen. De extra licenties tellen mee bij de bepaling van de p-, en de f-score zoals beschreven in paragraaf In verband met de beheerslast hebben de Gemeenten een voorkeur voor server/cpu based licenties. Geef de prijs per server/cpu voor het noodzakelijke aantal servers/cpu om de hiervoor genoemde load met een acceptabele performance te kunnen bedienen. Indien dit niet mogelijk blijkt, resulteert deze load in een bepaald aantal server/cpu licenties plus client licenties. Conform Eis E29 uit het bestek mogen deze client licenties niet named zijn, d.w.z. niet gebonden een bepaalde persoon of een bepaalde pc. Geef aan of en hoe de prijs afhankelijk is van het aantal (concurrent) gebruikers, aantal server/cpu, etc. 11 Bij interne midoffice koppelingen kan bijvoorbeeld worden gedacht aan koppelingen tussen het DMS en het Midoffice, tussen de Frontoffice en het Midoffice, tussen het Frontoffice en het DMS, tussen het Frontoffice en de GIS viewer, naar DigiD en Ogone, tussen het KCC en het Frontoffice, tussen het KCC en het Midoffice, tussen het KCC en het DMS en tussen het Midoffice (broker) en GIS, etc. Europese aanbesteding , 28 maart

112 Voor alle applicaties zoals DMS dient indien relevant zowel de light als de (volledige) enterprise variant te worden aangeboden. Daarnaast moet de Inschrijver aangeven/beargumenteren welke soort (light of enterprise) hij denkt nodig te hebben om de functionaliteit die in de antwoorden op de vragen (zie paragraaf 8.1.1) door de Inschrijver wordt genoemd te realiseren. DMS en CRM dient (indien noodzakelijk) inclusief de externe connector voor webtoegang te worden aangeboden. Software Applicatie 1, Naam 1 Licentiekosten Productieomgeving Specificeer (indien relevant) zowel voor de light als voor de enterprise variant: - licentiekosten per server/cpu - indien van toepassing, licentiekosten voor 250 concurrent users - indien van toepassing, licentiekosten voor 300 extra backoffice users - indien relevant: external connector 2 Licentiekosten Acceptatieomgeving Voor specificatie zie rij 1:.Licentiekosten Productieomgeving. 3 Licentiekosten Ontwikkel-/Testomgeving Voor specificatie zie rij 1:.Licentiekosten Productieomgeving. 4 Onderhoud en beheer van software Specificeer in detail wat hieronder wordt verstaan 14. Besteed aandacht aan bugfixes, upgrades, incident response afroep i.c.m. de mogelijke responstermijnen, etc. 5 Ondersteuning en support van software Specificeer in detail wat hieronder wordt verstaan 14. Besteed aandacht aan helpdesk, incident response op afroep i.c.m. de mogelijke responstermijnen, etc.. 6 Prijzen noodzakelijke add-ons Specificeer prijzen per add-on Add-on 1 Add-on 7 Hosting / ASP (optioneel) Specificeer - voor een volledige Midoffice Suite - per applicatie (indien separate hosting mogelijk) Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks Totaal 5 jaar Eenmalig Jaarlijks 13 Totaal 5 jaar Standaard gemeente ( inwoners) 12,,,,,,,,,,,,,,,,,,,,,,,, Beschrijf indien van toepassing ook de prijsafhankelijkheid voor software van het aantal inwoners, bijvoorbeeld m.b.v. een formule, zodat de Gemeenten zelf de kosten kan berekenen voor een Gemeente met een ander inwonertal, bijvoorbeeld voor een Gemeente van of inwoners. Indien de jaarlijkse kosten niet gelden voor het eerste jaar dan dient dit expliciet te worden aangegeven. Voeg eventueel een bijlage toe. Europese aanbesteding , 28 maart

113 8 Korting Specificeer: - bij gunning door 1, 2, 3, 4, 5, 6 en 7 Gemeenten. - houd rekening met applicaties die reeds bij Gemeenten aanwezig zijn 15 en die bijv. kunnen worden hergebruikt of ge-upgrade. - houd rekening met volgende ANDEZ aanbestedingen etc. 9 Escrow Geef aan of escrow van applicatiecode mogelijk is en of er kosten aan verbonden zijn. 10 Totale software kosten applicatie 1 (=som van bovenstaande) Specificeer met en zonder hosting / ASP Eenmalig Jaarlijks 13 Totaal 5 jaar Eenmalig Jaarlijks 17 Totaal 5 jaar Eenmalig Jaarlijks 18 Totaal 5 jaar,,,,,,,,, Applicatie 2, Naam Applicatie, Naam Totale kosten Software Specificeer met en zonder hosting / ASP, Zie de bijlagen in het Bestek In 2007 en later zal mogelijk nog een aantal gemeenten op basis van dit bestek (met eigen bijlagen) een midoffice oplossing aanbesteden. Geef aan wat de gevolgen zijn voor de korting op éénmalige licentiekosten, jaarlijkse licentiekosten, etc. Specificeer tevens de kick-back regeling. Indien de jaarlijkse kosten niet gelden voor het eerste jaar dan dient dit expliciet te worden aangegeven. Indien de jaarlijkse kosten niet gelden voor het eerste jaar dan dient dit expliciet te worden aangegeven. Europese aanbesteding , 28 maart

114 8.1.4 Prijzen maatwerksoftware Onder maatwerksoftware wordt verstaan het programmeren van een extra pakketmodule. Maatwerksoftware heeft dus het karakter van een softwarepakket/module/add-on. Dit betekent dat maatwerksoftware voor andere klanten (gemeenten) beschikbaar is en dat kickback van toepassing is. Bij een kickback-regeling geniet een Gemeente een terugverdieneffect, wanneer andere gemeenten aansluiten of u het voor de Gemeenten ontwikkelde maatwerksoftware en/of producten, processen en dergelijke vermarkt. Maatwerksoftware hangt qua kosten nauwelijks af van de Gemeente-inrichting. U dient alle maatwerksoftware die zal worden gerealiseerd te prijzen, inclusief implementatie, onderhoud, documentatie en ondersteuning hierbij voor 5 jaar. Maak een duidelijk onderscheid tussen maatwerksoftware die noodzakelijk is voor de generieke configuratie en specifieke implementatie van de Top-7 en maatwerksoftware voor de Top-34. Maatwerksoftware Applicatie 1, Naam 1 Geschatte kosten maatwerksoftware éénmalig, incl. implementatie en documentatie en (jaarlijks) onderhoud Licentiestructuur en eigenaarschap m.b.t. maatwerksoftware. Specificeer in detail wat hieronder wordt verstaan. 3 Mogelijke extra kosten bij toekomstige aanpassingen, upgrades of vervanging van (delen van) de software. Specificeer in detail wat hieronder wordt verstaan. Geef aan of het maatwerksoftware specifiek (alleen voor Gemeente X) of generiek (voor alle (evt. later aansluitende) gemeenten) is. In het laatste geval hoeven de kosten niet 100% aan de huidige ANDEZ2 Gemeenten te worden doorberekend. 4 Korting Specificeer: - bij gunning door 1, 2, 3, 4, 5, 6 en 7 Gemeenten. - houd rekening met vervolg aanbestedingen etc. 4 Escrow van maatwerkcode Geef aan of escrow van maatwerkcode mogelijk is en of er kosten aan verbonden zijn. Applicatie 2, Naam Applicatie, Naam Totale kosten maatwerksoftware Eenmalig Jaarlijks 21 Totaal 5 jaar Eenmalig Jaarlijks 21 Totaal 5 jaar Eenmalig Jaarlijks 21 Totaal 5 jaar Eenmalig Jaarlijks 21 Totaal 5 jaar Eenmalig Jaarlijks 21 Totaal 5 jaar Standaard gemeente ( inwoners) 19,,,,,,,,,,,,,,,, 19 Beschrijf indien van toepassing ook de prijsafhankelijkheid voor software van het aantal inwoners, bijvoorbeeld m.b.v. een formule, zodat de Gemeenten zelf de kosten kan berekenen voor een Gemeente met een ander inwonertal, bijvoorbeeld voor een Gemeente van of inwoners. 20 Conform Eis E23 uit het bestek moet maatwerksoftware blijvend worden ondersteund in volgende releases van de geoffreerde applicatie(s). 21 Indien de jaarlijkse kosten niet gelden voor het eerste jaar dan dient dit expliciet te worden aangegeven. 22 In 2007 en later zal mogelijk nog een aantal gemeenten op basis van dit bestek (met eigen bijlagen) een midoffice oplossing aanbesteden. Geef aan wat de gevolgen zijn voor de kosten van maatwerksoftware en specificeer de kick-back regeling. Europese aanbesteding , 28 maart

115 8.1.5 Initiële Implementatie De Initiële implementatie is het in overleg met de betreffende Gemeente inrichten (configureren) van de aangeboden midoffice suite, inclusief projectleiding, analyse, het schrijven van (functionele en technische) ontwerpen, communicatie e.d. Implementatie is dus gemeentespecifiek. De Gemeenten zullen dan ook op basis van onderstaande tabel per Gemeente een prijs voor de implementatie bepalen. De implementatiekosten uit deze paragraaf dienen de totale kosten van de initiële implementatie te omvatten voor een Gemeente die de volledige Midoffice Suite afneemt, met uitzondering van het optionele meerwerk uit paragraaf maar inclusief het inrichten van de volledige Top-7 producten. Het meer- en minderwerk t.g.v. het niet afnemen van een bepaalde optionele applicatie(component) ten opzichte van de volledige Midoffice Suite wordt uitgevraagd in paragraaf De implementatiekosten dienen te worden uitgesplitst in vijf hoofdgroepen: installatie, basisimplementatie, inrichten Top-7, externe backoffice koppelingen en eventuele migratie. Installatie De front- en 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), inclusief (voor zover relevant) CMS, CRM, DMS, broker, datadistributie, etc. 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 front- en midoffice dient in deze fase plaats te vinden. Daarnaast moeten eventuele ondersteunende applicaties zoals een webserver, applicatieserver en/of andere applicaties werkend zijn geïnstalleerd en moet een ontwikkel-, test- en acceptatie omgeving zijn ingericht. Basisimplementatie De basisimplementatie bevat de implementatie van de interne midoffice koppelingen. De implementatie en software van de externe midoffice koppelingen zijn geen onderdeel van de basisimplementatie (deze worden uitgevraagd in paragraaf 8.1.7). In paragraaf zijn deze koppelingen toegelicht. De installatie op resp. koppeling met de infrastructuur (database management systemen, directory server, server, telefooncentrale in het geval van CRM, etc.) zoals beschreven in bijlage 8.2 behoort wel tot de Installatie en basisimplementatie. Dik in te richten Top-7 producten Bij Dik inrichten Top-7 moet per product de implementatie voor een zgn. dikke uitvoering van het product worden gespecificeerd. Zie paragraaf van het Bestek voor een nadere toelichting op dik en dun. Een dikke inrichting m.b.v. een reeds bij de Gemeente aanwezig DMS/CRM moet hier als dun worden beschouwd. Geef in paragraaf het (verplichte) Europese aanbesteding , 28 maart

116 minderwerk aan implementatie indien gekoppeld moet worden met bestaande 3P componenten, zoals een reeds aanwezig DMS, CMS, etc. De kosten voor de gemeentebrede implementatie van dit 3P DMS, CMS, etc. zullen in paragraaf als optioneel meerwerk worden uitgevraagd. Om de scope van de Initiële implementatie van de Top-7 te bepalen, en m.n. van de implementatie van 1P DMS, CMS, etc. dient Inschrijver uit te gaan van de voorbeeld beschrijving in paragraaf 5.7 van het bestek. Om een eerlijke vergelijking tussen de diverse Inschrijvers mogelijk te maken is het aanbieden van de dikke inrichting (inclusief implementatie en documentatie) verplicht. Inschrijver dient per product (en dus niet per applicatie) een prijsrange te geven met een maximale afwijking van het prijsgemiddelde van maximaal 20% naar boven en naar beneden. Op basis van deze prijsopgave zullen de Gemeenten een gemiddelde prijs bepalen om de f- score te berekenen. Tijdens de PoC-fase zal aan Inschrijvers uit de top-n worden gevraagd om offertes per Gemeente op te stellen. Dikke inrichting omvat tenminste inrichting van frontoffice (PDC, formulieren, evt. koppeling met geo-viewer, etc, maar ook inrichting zakenmagazijn, inrichting gegevensmagazijn tbv. prefill, inrichting zakenmagazijn tbv. statusmeldingen, etc.), inrichting in het dikke midoffice (incl. inrichting zakenmagazijn, afhandeling processen en userinterface tbv. afhandeling) en eventuele conversie van bestaande formulieren en processen. Dun in te richten Top-7 producten Bij Dun inrichten Top-7 moet per product de implementatie voor een zgn. dunne uitvoering van het product worden gespecificeerd. Zie paragraaf van het Bestek voor een nadere toelichting op dik en dun. Een dikke inrichting m.b.v. een reeds bij de Gemeente aanwezig DMS, CMS, etc. moet hier als dun worden beschouwd. Bij een dunne inrichting van een product dient te worden gekoppeld met externe backoffices. De externe backoffice koppelingen zijn koppelingen tussen door de Inschrijver aangeboden midoffice applicaties (m.n. de broker) en 3P applicaties in een gemeentelijke backoffice, waarmee moet worden gekoppeld als onderdeel van de Initiële implementatie (van de Top-7). Per applicatie dient een transactie-, synchronisatie- en statuskoppeling te worden geleverd. Indien er bij een backofficeapplicatie geen adapter beschikbaar is, kan men voor alleen-lezen (status, synchronisatie) uit gaan van een directe databasekoppeling. Per Top-7 product worden de applicaties die bij één of meerdere Gemeenten in gebruik zijn genoemd en waarvoor een externe backoffice koppeling dient te worden gerealiseerd (vgl. bijlage 8.3 van het Bestek). Inschrijver dient per product (en dus niet per applicatie) een prijsrange te geven met een maximale afwijking van het prijsgemiddelde van maximaal 20% naar boven en naar beneden. Alle te prijzen koppelingen zijn inclusief implementatie, onderhoud, documentatie en ondersteuning hierbij voor 5 jaar. Op basis van deze prijsopgave zullen de Gemeenten een gemiddelde prijs bepalen om de f-score te berekenen. Tijdens de PoC-fase zal aan Inschrijvers uit de top-n worden gevraagd om offertes per Gemeente op te stellen. Om een eerlijke vergelijking tussen de diverse Inschrijvers mogelijk te maken is het aanbieden van de externe backoffice koppelingen (inclusief implementatie en documentatie) verplicht. Indien een bepaalde koppeling niet wordt aangeboden zal voor het bepalen van de f- Europese aanbesteding , 28 maart

117 score (zie paragraaf 2.5.4) de prijs van de ontbrekende koppeling gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfait-bedrag. Inschrijver mag ervan uitgaan dat de stekker aan de kant van de externe (3P) backoffice applicatie door de Gemeente wordt geleverd. Implementatie 23 1 Installatie Specificeer in detail wat hieronder wordt verstaan. 2 Basisimplementatie en integratie tussen de applicaties 25 Specificeer in detail wat hieronder wordt verstaan, voeg eventueel een bijlage toe. Standaard gemeente ( inwoners) 24 3 Dikke inrichting Top-7 26 Dik Specificeer in detail wat hieronder wordt verstaan bij uw aanbod, voeg eventueel een bijlage toe. Zie ook paragraaf 5.7 van het bestek: 1. Aanvragen afschrift GBA nvt 2. Aanvragen verhuizing (binnen- én intergemeentelijk) nvt 3. Indienen melding openbaar gebied - 4. Indienen generiek bezwaarschrift - 5. Aanvragen evenementenvergunning - 6. Aanvragen gecombineerde BKS -vergunning - 6a. Lichte bouwvergunning 6b. Kapvergunning 6c. Sloopvergunning 7. Intern: in- en uitdiensttreding - 4 Dunne inrichting Top-7 27 Dun 1. Aanvragen afschrift GBA (PIV4all, Probev, Cipers) - 2. Aanvragen verhuizing (binnen- én intergemeentelijk) - (PIV4all, Probev, Cipers) 3. Indienen melding openbaar gebied (Ultimo, MeldDesk, BWT4all, - Verseon 28 ) 4. Indienen generiek bezwaarschrift (BMU (maatwerk), Verseon 28 ) - 5. Aanvragen evenementenvergunning (VGU (maatwerk), Verseon 28 ) - 6. Aanvragen gecombineerde BKS -vergunning - 6a. Lichte bouwvergunning (BWT4all, Corsa 28, Menis) - 6b. Kapvergunning (VGU (maatwerk), Menis, Verseon 28 ) - 6c. Sloopvergunning Sloopvergunning (BWT4all, Menis) - 7. Intern: in- en uitdiensttreding - PIMS4all, Verseon 28 5 Migratie van DMS objecten (zie par 5.7) Zie ook paragraaf 5.7 en (Meer- en minderwerk) Beschrijf indien van toepassing ook de prijsafhankelijkheid van implementatie van het aantal inwoners, bijvoorbeeld m.b.v. een formule, zodat de Gemeenten zelf de kosten kan berekenen voor een Gemeente met een ander inwonertal, bijvoorbeeld voor een Gemeente van of inwoners. Inclusief (de implementatie en software van) de interne midoffice koppelingen. Exclusief de externe midoffice koppelingen. Inrichting frontoffice (PDC, formulieren, evt. koppeling met geo-viewer, etc, inrichting zakenmagazijn, inrichting gegevensmagazijn tbv. prefill, inrichting zakenmagazijn tbv. statusmeldingen, etc.), inrichting in het dikke midoffice (incl. inrichting zakenmagazijn, processen en userinterface tbv. afhandeling) en eventuele conversie van bestaande formulieren en processen. Inrichting frontoffice (PDC, formulieren, evt. koppeling met geo-viewer, etc, inrichting zakenmagazijn, inrichting gegevensmagazijn tbv. prefill, inrichting zakenmagazijn tbv. statusmeldingen, etc.), koppeling met de desbetreffende backoffice applicaties en eventuele conversie van bestaande formulieren en processen. N.B. dit betreft dus (grotendeels) dezelfde Frontoffice inrichting als bij het desbetreffende Top-7 product bij Dikke inrichting Top-7. Het betreft hier het DMS in de rol van backoffice applicatie. Europese aanbesteding , 28 maart

118 Specificeer in detail wat hieronder wordt verstaan Korting Specificeer: - voor installatie, basisimplementatie, inrichten Top-7 en migratie - bij gunning door 1, 2, 3, 4, 5, 6 en 7 Gemeenten. - houd rekening met applicaties die reeds bij Gemeenten aanwezig zijn en die bijv. kunnen worden hergebruikt of geüpgraded. - houd rekening met vervolg aanbestedingen in 2007 en later etc. Conform paragraaf van het bestek bevatten de bovengenoemde implementatiekosten voor wat betreft de inrichting van bijvoorbeeld het CMS en het DMS alleen de implementatie m.b.t. gebruik in het midoffice van de producten uit de Top-7, inclusief postregistratie en scannen, inclusief evt. conversie van reeds in gebruik zijnde elektronische formulieren en de bijbehorende magazijnen/processen, voor zover nodig voor de Top-7. Daarnaast moeten alle aanwezige documenten en objecten aanwezig in het DMS volledig gemigreerd worden. Overige implementatie, zoals volledige inrichting van het CMS (incl. redactie-inrichting voor volledige websites), volledige inrichting van het CRM/relatiebeheersysteem, volledige inrichting van een geografisch informatiesysteem (opslag en manipulatie), volledige (buiten de Top-7) inrichting van het datadistributiesysteem en / of een volledige inrichting van het DMS (incl. archivering) t.b.v. gemeentebreed gebruik, is optioneel meerwerk. Houd er rekening mee dat de Gemeenten streven naar enige standaardisatie op het gebied van formulieren, processen en magazijninrichting, maar dat verschillen tussen individuele Gemeenten niet zijn uitgesloten. Het is dus niet toegestaan om uit te gaan van een standaard inrichting voor alle Gemeenten Voeg eventueel een bijlage toe. In 2007 en later zal mogelijk nog een aantal gemeenten op basis van dit bestek (met eigen bijlagen) een midoffice oplossing aanbesteden. Europese aanbesteding , 28 maart

119 8.1.6 Training en documentatie De uitgangspunten voor de training zijn: 1) dat de gebruikers met de relevante functionaliteit overweg kunnen 2) dat beheerders van de Gemeente zelfstandig de midoffice kunnen beheren en 3) dat ontwikkelaars (met beperkte begeleiding van de implementatiepartner) nieuwe producten kunnen implementeren. 4) Opleidingen zullen niet allemaal tijdens de initiële implementatietermijn worden afgenomen en zijn op afroep af te nemen door de Gemeenten voor de duur van de overeenkomst. Zie ook Eis E34 in het Bestek. Nr Training en documentatie Eerste training 1 Geef de prijs voor het opleiden van 100 eindgebruikers in de vorm van een groepstraining op locatie van de Inschrijver, inclusief documentatie voor alle deelnemers. 31 Specificeer 32 : - aantal dagen training per product en trainingskosten per dag (bij voorkeur per docent/groep) - het minimale en maximale aantal deelnemers van een groep. - hoeveel kosten er voor de trainer aan voorbereiding zijn. - het verschil (bijv. in voorbereidingskosten) tussen de eerste training en latere trainingen. - of de kosten lager zijn indien de training plaats vindt bij de Gemeente. Beschrijf welke eisen aan de locatie bij de Gemeente worden gesteld, zoals het aantal cursisten per werkplek. - mogelijke besparingen door het gebruik van het train-de-trainer principe. - welke trainingen er voor ieder product noodzakelijk zijn, hoeveel tijd de trainingen in beslag nemen en wat de kosten zijn. voor ieder product de mogelijkheden voor en kosten van een individuele training. 2 Geef de prijs voor het opleiden van 5 beheerders op locatie van de Inschrijver, inclusief documentatie voor alle deelnemers. 31 Specificeer: zie rij 1 van deze tabel 3 Geef de prijs voor het opleiden van 5 ontwikkelaars op locatie van de Inschrijver, inclusief documentatie voor alle deelnemers. 31 Specificeer: zie rij 1 van deze tabel 4 Documenten eindgebruiker (licentiekosten) Voorkeur gaat uit naar elektronische documentatie die door eindgebruikers zelf te printen is. Geef aan wat de licentiekosten en eventuele overige kosten van de documentatie zijn. 5 Documenten beheerders Zie 4 6 Documenten ontwikkelaars Zie 4 7 Korting Specificeer: - op training en documentatie - bij gunning door 1, 2, 3, 4, 5, 6 en 7 Gemeenten. - houd rekening met vervolg aanbestedingen en kick-back etc. Per volgende training,,,,,,,,,,,,,, Geef zowel de prijs voor de eerste training als voor vervolgtrainingen. Voeg eventueel een bijlage toe. In 2007 en later zal mogelijk nog een aantal gemeenten op basis van dit bestek (met eigen bijlagen) een midoffice oplossing aanbesteden. Geef aan wat de gevolgen zijn voor de korting op koppelingen, etc. Specificeer tevens de kick-back regeling. Europese aanbesteding , 28 maart

120 8.1.7 Verplicht meer- / minderwerk Indien een Gemeente een bepaalde applicatie(component) ten opzichte van de volledige Midoffice Suite niet afneemt, heeft dit meer- en minderwerk tot gevolg. Het meerwerk bestaat uit een koppeling met de 3P applicatie(s) van de Gemeente. Deze 3P midoffice koppelingen zijn het eerste onderwerp van deze paragraaf. Het minderwerk bestaat uit de softwarekosten en de implementatiekosten voor de betreffende applicatie(s). De softwarekosten zijn reeds gespecificeerd in paragraaf De minderwerk implementatiekosten zijn het tweede onderwerp van deze paragraaf. Om een eerlijke vergelijking tussen de diverse Inschrijvers mogelijk te maken is het aanbieden van het meer- en minderwerk in deze paragraaf verplicht. Indien een bepaald onderdeel niet wordt aangeboden zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van het ontbrekende onderdeel gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfait-bedrag. Meerwerk Het meerwerk t.g.v. externe midoffice koppelingen is aanvullend op de implementatiekosten uit paragraaf Alle te prijzen koppelingen zijn inclusief implementatie, onderhoud, documentatie en ondersteuning hierbij voor 5 jaar. Inschrijver mag ervan uitgaan dat de stekker aan de kant van de externe (3P) mid- of backoffice applicatie door de Gemeente wordt geleverd. Dit meerwerk ten gevolge van externe midoffice koppelingen betreft uitsluitend koppelingen tbv. de generieke midoffice architectuur en de koppelingen die nodig zijn om de Top-7 producten in te richten. De externe midoffice koppelingen zijn koppelingen tussen door de Inschrijver aangeboden applicaties en 3P applicaties bij een Gemeente, die weliswaar voorzien in (een aantal van) bovengenoemde componenten en in die hoedanigheid onderdeel uitmaken van een midoffice, maar die niet in het kader van deze aanbesteding door de Inschrijver aan de Gemeente worden geleverd 34. Onderstaande tabel bevat de midoffice componenten en per component de applicaties die bij één of meerdere Gemeenten in gebruik zijn en waarvoor een externe midoffice koppeling dient te worden gerealiseerd (vgl. bijlage 8.4 van het Bestek). Inschrijver dient per component (en dus niet per specifieke applicatie) een prijsrange te geven met een maximale afwijking van het prijsgemiddelde van maximaal 20% naar boven en naar beneden. Op basis van deze prijsopgave zullen de Gemeenten een gemiddelde prijs bepalen om de f-score te berekenen. Tijdens de PoC zal aan Inschrijvers uit de top-n worden gevraagd om offertes per Gemeente op te stellen en de koppelingen nader te specificeren. 3P componenten Te koppelen 3P midoffice applicaties 35 Prijsrange meerwerk Webintake (WIS) Discovery Server, ICTU eformulieren,, -, SIMeForm GIS-viewer NedBrowser, FlexiWeb, -, GIS (server: opslag, mapserver, NedGraphics, MicroStation, Omega, NetGuide, GeoWeb Solutions, GeoWeb Publisher, Oracle, -, Bij externe midoffice koppelingen kan bijvoorbeeld worden gedacht aan een koppeling met een 3P DMS of een 3P CMS. Zie ook de referentietabellen in bijlagen 8.2, 8.3 en 8.4. Europese aanbesteding , 28 maart

121 3P componenten Te koppelen 3P midoffice applicaties 35 Prijsrange meerwerk contourserver, migratie van huidige gegevens, manipulatietools) Spatial, IGOS NGDM, Vicrea Stroomlijn, webmapservices, MapGuide, ArcView, MAP4all, AutoCad PDC (inclusief zoeken en / of vraaggeleiding) CMS DMS inclusief postregistratie en WfM 36 Segment OPUS, Ifocus, SmartSite, VIND(web)2, Tsjil CMS als ASP, Digitaal Loket Vincis, GX WebManager Ifocus, SmartSite, Tsjil als ASP, Vincis CastManage, WEB4all R2, Ordina TXO, GX WebManager, SIMsite Verseon, Corsa, -,, -,, -, Datadistributie DDS4all, BRS, -, Gegevensmagazijn NGDM, NedGraphics, Oracle Spatial, SAP, -, Business Warehouse, ESRI, ArcGis, etc Zakenmagazijn 37 Verseon, Corsa, -, CRM/Relatiebeheer Post4U, Decos Post Pro, PerfectView, -, Imaging hard- en software Ricoh MFP, Canon/Nashuatec, Corsa, Nashuatec, easyseparate, DocMan, etc. Overige SharePoint 2007 (Zie Maastricht), -,, -, Korting, -, Specificeer: - bij gunning door 1, 7 Gemeenten van dezelfde koppeling - houd rekening met vervolg aanbestedingen etc. Minderwerk Inschrijver dient in onderstaande tabel voor iedere applicatie(component)aan te geven hoeveel minderwerk in termen van implementatie het niet afnemen van een bepaalde applicatie(component) m.b.t. de kosten van de Initiële implementatie oplevert. Een voorbeeld is het niet ontwikkelen van formulieren bij koppeling met een 3P WIS. Hoewel de exacte kosten afhankelijk zijn van de keuzes die een Gemeente heeft gemaakt t.a.v. de Top-7 (bijv. welke producten er dun en welke er dik worden uitgevoerd) wordt Inschrijver verzocht om in deze tabel een prijs te geven die onafhankelijk is van de Gemeenten. Vanwege de onzekerheid is het toegestaan om een prijsrange te geven met een maximale afwijking van het prijsgemiddelde van maximaal 20% naar boven en naar beneden. Component Webintake (WIS), inclusief Ogone en DigiD GIS client: viewer (inclusief koppeling Prijsrange implementatie minderwerk, -,, -, Het betreft hier een koppeling met het DMS in de rol van externe midoffice applicatie / document repository. Het betreft hier een koppeling met het DMS in de rol van externe midoffice applicatie. In 2007 en later zal mogelijk nog een aantal gemeenten op basis van dit bestek (met eigen bijlagen) een midoffice oplossing aanbesteden. Europese aanbesteding , 28 maart

122 Component met bestaande geo systemen) PDC (inclusief vraaggeleiding en zoeken) CMS DMS/RMA, WfM Datadistributie Gegevensmagazijn (inclusief eventueel geo-magazijn) Zakenmagazijn CRM Overig (specificeer) Prijsrange implementatie minderwerk, -,, -,, -,, -,, -,, -,, -,, -, Europese aanbesteding , 28 maart

123 8.1.8 Optioneel meerwerk Het meeste meerwerk is reeds gevraagd in de vorm van koppeling met 3P applicaties. Onderstaand meerwerk is optioneel te offreren. Optioneel meerwerk wordt niét gebruikt ter bepaling van de f-score (zie paragraaf van dit prijssjabloon. Alle te prijzen optioneel meerwerk is inclusief implementatie, onderhoud, documentatie en ondersteuning hierbij voor 5 jaar. Waar niet expliciet om alleen de implementatie wordt gevraagd, wordt steeds software inclusief implementatie bedoeld. Inschrijver mag ervan uitgaan dat eventuele stekkers aan de kant van de externe (3P) mid- of backoffice applicatie door de Gemeenten worden geleverd. Optioneel meerwerk GIS servers (mapserver, contourendatabase, gis-manipulatie, etc) Implementatie organisatiebreed CMS, buiten de scope van het Midoffice Implementatie organisatiebreed DMS, buiten de scope van het Midoffice Inrichting Milieuvergunning tbv Veghel Imaging (scanstraat) Implementatie Top-7 in het bestaande Verseon (Barendrecht) Implementatie Top-7 in het bestaande Verseon (Barneveld) Ontsluiting managementinformatie (Cognos, etc) Overig (specificeer) Prijsrange implementatie meerwerk, -,, -,, -,, -,, -,, -,, -,, -,, -, Europese aanbesteding , 28 maart

124 8.1.9 Tarieven & Opslagen Geef per functieprofiel aan welke tarieven u hanteert voor de door u geoffreerde teamleden. Indien u als Combinatie aanbiedt dient u de profielen en tarieven te synchroniseren. Profiel Projectmanager Projectleider Projectleider Projectleider Projectleider Netwerkspecialist System specialist Uurtarief,,,,,,, Geef bovendien aan wat hun overwerk- en weekendtarieven zijn. Conform Eis E35 mogen de tariefopslagen maximaal 150% zijn. Indien u als Combinatie aanbiedt dient u de opslagen te synchroniseren. Tijden Tariefopslag (percentage) Werkdagen van 18:00 tot 20:00 uur % Werkdagen van 20:00 tot 07:30 uur % Zaterdagen, zondagen en christelijke % feestdagen Anders % Europese aanbesteding , 28 maart

125 Beheer Om een indruk te krijgen van de verwachtte beheerskosten voor een Gemeente vragen wij u onderstaande tabel in te vullen. Specificeer het benodigde beheer in aantal fte (full-timeequivalents) per jaar (met decimalen) voor de gehele Midoffice Suite. Ga uit van een standaard gemeente met ongeveer inwoners, die nog geen MO Suite of equivalent heeft, doch wel één of meer websites, incl. PDC etc. doch zonder formulieren, brokers, magazijnen en KCC systeem (DMS/CRM). We realiseren ons dat het antwoord mede afhankelijk is van de bestaande kennis/ervaring binnen de Gemeente, doch een indicatie op basis van bijv. referentie gemeenten wordt op prijs gesteld. NB. Het is ondenkbaar dat Gemeenten totaal meer dan enkele fte per jaar extra moeten inzetten voor het beheer van de midoffice suite. Geef per applicatie de onderliggende technologie, het aantal fte voor technisch en voor functioneel beheer. Applicatie 39 Technologie 40 Technisch beheer (# fte/jaar) Applicatie 1, Naam Applicatie 2, Naam Applicatie Middleware (excl. DMBS en operating systeem) Overig Midoffice Suite Functioneel beheer (# fte/jaar) Totaal (som alle Applicaties en middleware) Dit zijn de in paragraaf genoemde applicaties. Bijv. MS.Net, Java, C++, Oracle Forms, Oracle PL/SQL, etc. Europese aanbesteding , 28 maart

126 8.2 Huidige infrastructuur Infrastructuur Barendrecht Barneveld Maastricht Utrecht Veghel Operating systemen MS Windows XP, terminal server (client) Office versie(s) (client) Browser versie(s) (client) Hardware (server) Operating systemen (server) MS Office 2003 MS Office 2000 SP3 MS Windows 2000 MS Windows (XP) MS Windows XP 275x MS Windows XPe, 12x MS Windows 2003+Citrix 3.0, 19 x MS Windows XP MS Office 2000 SP3. (wordt nog dit jaar MS Office 2007) MS Office 2003 Pro MS Office 2003 MS IE 6 MS IE 6 SP1 MS IE 6 SP2 MS IE MS IE 6 en 7 HP-UX, IBM servers tbv VMware x86, Xeon x86 en HP-UX (11i) HP Proliant 360 DL (3 GHz Intel Xeon, 1 GB) en HP-Compaq (3.2 Ghz Intel Pentium 4 HT, 256 MB) MS Windows 2003 Unix HP Proliant DL en ML servers 1x HP9000- RP3440 VMWare ESX 2.53 (wordt versie 3.01). Novell Netware 6.5 Windows2003, Linux Redhat Enterprise v.4.0 SP 5. Microsoft Windows HP-UX Webservers MS IIS, Apache MS IIS 6, Apache MS IIS en Apache MS IIS MS IIS 6 Applicatieservers Novell, MS Windows Server MS Windows Server 2000 en 2003 Database servers HP-UX Linux RedHat Enterprise V4.0 Database Management Systemen Telefooncentrale MS Windows Server (2003) en HP-UX Oracle 9i, Spatial Oracle 9i of 10g Oracle (9i) en MS SQL Server 2000 Alcatel Omnivista 4760 MS Windows 2003 HP-UX 11 HP-UX 11, MS Windows 2003, Citrix 3.0 x86 en HP-UX Oracle HP-UX 11 en MS Windows 2003 MS SQL, DB2, Oracle (verschillende versies) Nortel Succession HiPath 4000 Hybride centrale PABX en VOIP (Avaya) Oracle en MS SQL 2000 Sopho IS3050 Groupware (client) Novell GroupWise MS Outlook 2000 MS Outlook 2000 MS Outlook MS Outlook 2003 SP3 (wordt nog dit jaar MS Outlook 2007) Groupware (server) Novell GroupWise MS Exchange 2000 MS Exchange 2003 MS Exchange MS Exchange 2003 MS Windows Server 2003, HP- UX, AS400 Identity Novell E-directory MS Active Directory management Managementinformatie Cognos PowerPlay, Impromptu Financieel systeem Centric FIS4all Centric FIS@all v Personeelsadministratie ETL tools Cognos Powerplay, Impromtu MS Active Directory 2003 Cognos (zie ook bijlage Maastricht) Coda 10 MS Active Directory Cognos Impromptu Bussines Objects SAP (PinkRoccade CiVision Middelen) MS Active Directory 2003 LDAP Cognos Impromptu Centric FIS4all, FIS@All, per januari 2008 RAET Beaufort Centric PIMS@all RAET Beaufort Centric PIMS4all Centric PIMS@all PowerCenter Datawarehouses Imaging Geen, mogelijk NedGraphics Ricoh MFP multifunctionals easy separate, koppeling Verseon Oracle databases, NGDM voor GEO Canon/Nashuatec Oracle (zie ook bijlage Maastricht) oa BCT Corsa Case tbv Coda (zie ook bijlage Maastricht) Oracle Spatial, SAP Business Warehouse Nashuatec (harden software) met koppeling Corsa ESRI GeoDatabase in Oracle Spatial tbv geo-informatie Nashuatec multifunctionals easyseparate, koppeling DocMan Europese aanbesteding , 28 maart

127 Office versie(s) MS Office 2003 SP2 Standaard (client) Browser versie(s) (client) Hardware (server) x86, RS6000, I- series Operating systemen (server) Webservers Applicatieservers Database servers Database Management Systemen Telefooncentrale Linux based wyse terminal 95%, MS Windows 2000 en XP MS Office 2000 Word, Excel, Outlook 2003 MS Windows 2000, XP, CE (terminal) MS Office 2000 of hoger MS Office XP of hoger MS IE 6 MS IE 6 MS IE 6 en 7 MS IE 6, 7 Fire fox 2.02 MS Windows 2003, 2000 (enkele) AIX, Linux, OS400 HP 9000 RP5430 Parisc, HP-UX 11, X86 HP Proliant divers MS Windows 2000 en 2003 MS IIS 6, Apache 2 Lotus, Apache, MS IIS MS Windows Server 2003 IBM AIX, IBM OS/400, MS Windows 2003 Oracle 9i of 10g, MS SQL, MySQL, DB2 (wordt uitgefaseerd) Avaya S8500 MediaServer, Avaya Communication manager 2.0 MS Windows 2000 en 2003, HP-UX, Citrix Presentation server 3.x 8 servers MS Windows 2003, HP-UX Oracle 8.17 en 9i, MS SQL 2005, InterBase Nu coral2 pbx, doen mee aan OT2006 centrale x86, Dell PowerEdge en HP Proliant divers, HP9000 RP2430 RP2470, HP-UX 11 MS Windows 2000 en 2003, Netware 5 x86 HP Proliant divers, HP 9000, L1000, HP-UX 11 Primair Netware 6.5 SP6, Secundair beperkt Win 2003 (R2) Infrastructuur Venlo NOFA Achtkarspelen Dongeradeel Dantumadeel Operating systemen MS Windows XP MS Windows XP, SP2 thin client (beperkt) (client) Kollumerland MS Windows XP MS Office 2003 MS IE 6,7 x86 Dell Poweredge divers, HP 9000 RP2470, HP-UX 11 MS Windows 2003 MS IIS 5 en 6 Apache, MS IIS 6 MS ISS 6 MS Windows 2000 en 2003, HP-UX, Citrix Metaframe XP 50 lic Nu een Avaya Index. Doen mee aan OT2006. vervanging in 2007 gewenst. Groupware (client) MS Outlook 2003 MS Outlook 2003 MS Outlook 2000, 2003, XP HP-UX, MS Windows 2003, Novell, Linux, Citrix Presentation server 30 lic HP-UX,Linux, MS Windows 2003 Oracle 9i, MySQL, MS SQL 2000, InterBase Sopho 3000 KPN/ Philips centrale, vervanging 2007 gewenst doen mee aan OT2006 Novell GroupWise Client 7.01 en webbased Groupware (server) MS Exchange 2003 MS Exchange 2003 MS Exchange 2003 Novell GroupWise 7.01 Identity management MS Windows 2000 en 2003, HP- UX Oracle 9i, MS SQL 2000, InterBase Managementinformatie Financieel systeem Personeelsadministratie ETL tools MS Active Directory 2003 LDAP Cognos PowerPlay, Impromptu, MS Excel Oracle OneWorld Enterprise 1 versie 8.10 Centric PIMS4all + Web4PIMS MS Active Directory, LDAP Cognos Impromptu Centric FIS@all MS Active Directory, LDAP, NDS Cognos PowerPlay, Impromptu, SAP voor Financien PinkRoccade CiVision en Innen Novell E-directory, met DIRXML koppeling naar MS Active Directory, LDAP Cognos PowerPlay, Impromptu Centric FIS4all 2.14 HP-UX, MS Windows 2003 HP-UX, MS Windows 2003 Oracle 9i, MS SQL 2005 Nu businessphone 5510 pbx, doen mee aan OT2006 centrale MS Outlook 2003 MS Exchange 2003 MS Active Directory, LDAP Cognos Impromptu Procura ProFin terminal based Centric PIMS@all Centric PIMS@all Centric PIMS@all Centric PIMS@all Datawarehouses filebased filebased filebased filebased, NedGraphics geodatabase Europese aanbesteding , 28 maart

128 Circle DocMan, Centric GWS4all Multifunctionals met scanfuctie (10 stuks), alleen aan (beperkt) Easy Archive van Easy Software, Fujitsu A3 scanner, A0 scanner komt Decos Post Professional 5.0, OCE bulkscanner Infrastructuur Venlo NOFA Achtkarspelen Dongeradeel Dantumadeel Imaging Kollumerland Decos (beperkt), HP 9200C netwerk scanner Europese aanbesteding , 28 maart

129 8.3 Gemeentelijke applicaties (top-7) Onderstaand volgt een overzicht van de beoogde inrichting van de Top-7 producten. Als er al een applicatie aanwezig is waar mee gekoppeld dient te worden ( dun midoffice), wordt deze genoemd. Wanneer er een generieke applicatie gewenst is ( dik midoffice), wordt dit middels dik aangeduid. Indien relevant voor conversiedoeleinden wordt tussen haakjes eveneens de reeds aanwezige applicatie genoemd. Producten Barendrecht Barneveld Maastricht Utrecht Veghel 1 Aanvragen afschrift GBA Centric PIV4all Centric PIV4all Procura ProBev Centric PIV4all Centric PIV4all 2 Verhuizing (binnen- én Centric PIV4all intergemeentelijk) of dik 3 Indienen melding openbaar Ultimo gebied 4 Indienen generiek bezwaarschrift 5 Aanvragen evenementenvergunning Centric PIV4all Procura ProBev Centric PIV4all Centric PIV4all Circle Verseon Circle Verseon Circle Verseon dik Circle Verseon Circle Verseon dik BeheerVisie MeldDesk BWT4all BMU, bewonersmelding en Utrecht Maatwerk Ordina VGU (vergunningen gemeente Utrecht) 6 Aanvragen gecombineerde Circle Verseon BKS-vergunning 6a Lichte bouwvergunning Circle Verseon BWT4all BCT Corsa 6.3 BWT4all 6b Kapvergunning Circle Verseon Circle Verseon dik Maatwerk Ordina VGU (vergunningen gemeente Utrecht) 6c Sloopvergunning Circle Verseon Centric BWT4all dik Centric BWT4all 7 Intern: in- en uitdiensttreding BeheerVisie Melddesk of dik dik dik Menes Of dik Menes Of dik Menes of dik Circle Verseon Circle Verseon dik Centric PIMS4all dik Europese aanbesteding , 28 maart

130 Producten Venlo NOFA 1 Aanvragen afschrift GBA PinkRoccade Cipers IZRM 2 Verhuizing (binnen- én PinkRoccade intergemeentelijk) Cipers IZRM 3 Indienen melding openbaar gebied 4 Indienen generiek bezwaarschrift BeheerVisie MeldDesk dik (Circle DocMan) PinkRoccade Cipers 1.05 PinkRoccade Cipers 1.05 dik (eigen mdb file) dik (POST4U) Procura ProBev terminal based Procura ProBev terminal based dik / evt. dun (PerfectView / NedGraphics) dik (Centric WPW4all) Centric PIV4all 3.50 Centric PIV4all 3.50 dik (Decos Post Professional 5.0) dik (Decos Post Professional 5.0) 5 Aanvragen evenementenvergunning dik dik dik dik dik 6 Aanvragen gecombineerde BKS-vergunning 6a Lichte bouwvergunning BIMAS dik dik dik of dik (Provas) (Provas) (GISVG-AVR) 6b Kapvergunning dik (Circle DocMan dik dik dik dik 3.3) 6c Sloopvergunning BIMAS / evt dik 7 Intern: in- en uitdiensttreding dik (Provas) dik (Provas) dik (GISVG-AVR) Achtkarspelen Dongeradeel Dantumadeel Kollumerland PinkRoccade Cipers 1.05 PinkRoccade Cipers 1.05 dik (Syncera StraMis, Decos) dik (Decos Post Professional 5.0) dik (Provas) dik (Provas) dik (e-formulier) dik dik dik dik Europese aanbesteding , 28 maart

131 8.4 Aanbesteding, meer- en minderwerk Niet elke gemeente zal met zekerheid ieder component afnemen, of kan conform paragraaf wellicht één of meer onderdelen en/of componenten niet of niet direct afnemen. In deze bijlage volgt een samenvatting van de aanwezige applicaties waar wellicht mee gekoppeld of van gemigreerd zal moeten worden. Wanneer een gemeente een bepaald component niet wil afnemen, wordt u geacht te koppelen met de aanwezige applicaties. De bij de gemeente al aanwezige applicaties zijn daartoe hier weergegeven. De rij overig geeft een indicatie van mogelijk optioneel meerwerk; de gemeentespecifieke bijlagen gaan hier dieper op in. Waar deze overzichtstabel afwijkt van die gemeentespecifieke bijlagen, zijn die bijlagen leidend. Legenda Voornemens De gemeente is in principe voornemens deze component af te nemen, afhankelijk van het aanbod en de fit daarvan met de gemeente. Indien relevant voor migratie, conversie en/of integratie is de aanwezige applicatie ter informatie tussen haakjes genoemd. De gemeente wil dus ook de optie open houden met de aanwezige applicatie te koppelen. Wanneer de aangeboden component niet wordt afgenomen, zal er dus minderwerk zijn in de vorm van het niet afnemen van de betreffende component en meerwerk in de vorm van koppelen met de aanwezige applicatie. Interesse De gemeente is in principe niet voornemens deze component af te nemen. Afhankelijk van het aanbod en de fit daarvan met de gemeente, kan de gemeente dit echter heroverwegen. Indien relevant voor migratie, conversie en/of integratie is de reeds aanwezige applicatie ter informatie tussen haakjes genoemd. De gemeente wil dus de optie open houden met de aanwezige applicatie te koppelen. Wanneer de aangeboden component niet wordt afgenomen, zal er dus minderwerk zijn in de vorm van het niet afnemen van de betreffende component en meerwerk in de vorm van koppelen met de aanwezige applicatie.. Europese aanbesteding , 28 maart

132 Aanbesteding meer- en minderwerk Barendrecht Barneveld Maastricht Utrecht Veghel Broker + adapters Voornemens Voornemens Voornemens Voornemens Voornemens Datadistributie Interesse (Centric DDS4all) Interesse (Centric DDS4all) Interesse (Centric DDS4all) Voornemens (Centric DDS4all) Voornemens Webintake (+ koppeling met DigiD en Ogone) Gegegevensmagazijn Zakenmagazijn Interesse (Green Valley Discovery Server) Voornemens (Centric DDS4all en IGOS NGDM) Interesse (Circle Verseon) Voornemens Voornemens Interesse (Circle Verseon) Voornemens (GX WebManager 7.2) Voornemens (Centric DDS4all, ETL-tools) Voornemens (maatwerk GX) Interesse (ICTU eformulieren) Interesse Interesse Interesse (Segment SIMeForm) Voornemens Voornemens Document management Postregistratie Workflow management Relatiebeheer Interesse (Circle Verseon) Interesse (Circle Verseon) Interesse (Circle Verseon) (PerfectView relatiebeheer OH) Interesse (Circle Verseon) Interesse (Circle Verseon) Interesse (Circle Verseon) Voornemens (BCT Corsa Post 6.3 en Square DMS tbv Sociale Zaken) Voornemens (BCT Corsa Post 6.3) Voornemens (BCT Corsa Case 7.1) Interesse (BCT Corsa) Interesse (BCT Corsa) Interesse Voornemens (Circle DocMan) Voornemens (Circle DocMan) Voornemens Interesse Voornemens Interesse Voornemens Geo-informatie (client: viewer) Geo-informatie (server: manipulatie) Content management Productdienstencatalogus (incl. vraaggeleiding/zoeken) Overig (niet verplicht te offreren) Intersees (NedGraphics NedBrowser) Interesse (NedGraphics, IGOS, NGDM) Interesse (Green Valley Discovery Server) Interesse (Segment OPUS) Interesse (NedGraphics NedBrowser) Interesse (NedGraphics, IGOS, NGDM, AutoDesk) Interesse (ifocus) Interesse (ifocus) Interesse (Bentley FlexiWeb) Interesse (MicroStation 8, Omega 3.0, NetGuide, GeoWeb Solutions, GeoWeb Publisher) Voornemens (GX WebManager 7.2) Voornemens (GX WebManager 7.2 icm BWise 2.2 SP6) Koppeling met SharePoint Imaging (software tbv scanstraat). Elek. ondertekenen en waarmerken Interesse Interesse (Oracle Spatial, Vicrea Stroomlijn, webmapservices) Interesse (Seneca SmartSite) Interesse (Seneca SmartSite) Voornemens (FlexiWeb, alleen tbv intranet) Interesse (ESRI ArcGis Server Basic) Interesse (Segment SIMsite) Interesse (Segment OPUS) Extra product: milieuvergunning (dun, Menes) Europese aanbesteding , 28 maart

133 Aanbesteding meer- en minderwerk Venlo NOFA Dongeradeel Dantumadeel Achtkarspelen Kollumerland Broker + adapters Voornemens Voornemens Voornemens Voornemens Voornemens Datadistributie Webintake (+ koppeling met DigiD en Ogone) Voornemens (PinkRoccade BRS, DDS-client voor Centric applicaties) Voornemens (DigiD, Ogone) Voornemens (PinkRoccade BRS, alleen voor GBA en Sociale zaken) Voornemens Voornemens (Centric DDS4all 2.90, op basis XML, UBM 3.1, koppeling VOA 2.50, LRD viewer 1.1. Alle Centric apps gekoppeld) Interesse (ICTU eformulieren) Voornemens Gegegevensmagazijn Voornemens Voornemens Voornemens Voornemens Voornemens Zakenmagazijn Voornemens Voornemens Voornemens Voornemens Voornemens Document management Voornemens (Circle DocMan 3.3) Voornemens (Post4U, filebased) Voornemens (Centric WPW4all, filebased + Easy Archive, zie bijlage) Voornemens (Centric WPW4all) Voornemens (Decos Post Profesional 5.0 / GroupWise 7.0) Voornemens (Decos Post Profesional 5.0) Postregistratie Voornemens (Circle DocMan 3.3) Voornemens Voornemens (Decos Post profesional 5.0) Voornemens (Decos Post profesional 5.0) Workflow management Voornemens Voornemens Voornemens Voornemens Voornemens Relatiebeheer Voornemens Interesse Interesse Interesse Interesse Geo-informatie (client: viewer) Geo-informatie (server: manipulatie) Content management Productdienstencatalogus (incl. vraaggeleiding/zoeken) Overig (niet verplicht te offreren) Voornemens (NedGraphics NedOffice) Voornemens (Nedgraphics NedOffice, AutoDesk AutoCAD) Voornemens (maatwerk Systemec) Voornemens (BPI VINDweb2) Voornemens (NedGraphics NedView, IGOS met NGDM) Interesse (IGOS, ArcView) Interesse (Tsjil als ASP) Interesse (in CMS van Tsjil als ASP) Voornemens (NedGraphics NedView, NedOffice, IGOS met NGDM) Interesse (NedGraphics NedView, IGOS) Interesse (Vincis Castmanage) Interesse (Vincis Digitaal Loket module) Voornemens (Centric Map4all ArcView, ArxExplorer) Interesse (MicroStation XE, ArcView, Centric MAP4all ) Interesse (Centric WEB4all R2) Interesse (VIND2) Voornemens (NedBrowser, MapInfo) Interesse (NedGraphics) Interesse (Ordina TXO) Interesse (eigen mdb file) Europese aanbesteding , 28 maart

134 8.5 Kentallen gemeenten Gemeente Aantal inwoners Aantal medewerkers Aantal werkplekken Barendrecht ca Barneveld ca Maastricht ca NOFA Samen ca ( ) Utrecht ca ca Veghel ca Venlo ca ,350 1,150 Europese aanbesteding , 28 maart

135 8.6 Beschrijving Proof of Concept Inleiding Door middel van de Proof of Concept (PoC) wordt beoogd aan te tonen dat met de aangeboden applicatie(s) de genoemde functionaliteiten kunnen worden gerealiseerd. Tijdens de PoC willen de gemeenten, behalve een succesvolle installatie, graag zien dat de Inschrijvers een aantal minimale functionaliteiten realiseren. Deze paragraaf geeft een indicatie van de PoC, het is echter mogelijk dat hieraan bij aanvang nog aanvullende eisen gesteld worden. Er zal één centrale PoC gehouden worden, dus niet één per gemeente. Bij de Proof of Concept zijn alle Inschrijvers betrokken die in de Top-3 van een Gemeente zitten. Per Inschrijver wordt een vergoeding van 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 Gemeenten een opdracht gegund wordt. De teamleden die betrokken zijn bij de PoC, dienen tevens in gelijkwaardige hoedanigheid betrokken te zijn bij de Initiële implementatie. Het geoffreerde team dient het resultaat van de Proof of Concept te demonstreren en verduidelijken. Voor de PoC gelden de algemene voorwaarden in bijlage 1.1. Inschrijver dient zich expliciet akkoord te verklaren met de gestelde voorwaarden. Na het uitvoeren van de PoC zal het resultaat per gemeente worden beoordeeld op de onderstaande aspecten (mate waarin wordt voldaan aan aspecten: Resultaat PoC Midoffice Suite) Deze scores worden per Gemeente verwerkt in de definitieve kwaliteitsscore q. Tevens worden de antwoorden op het programma van eisen gecontroleerd, inclusief het implementatie team voor zover dat bij de PoC betrokken is en kan de Offerte per gemeente worden verduidelijkt op basis waarvan een definitieve prijsscore p en totaalscore f wordt bepaald, op basis waarvan per gemeente een definitieve Top-3 zal worden bepaald.. Desgewenst (zie ook paragraaf 2.2.3) wordt de opdracht, bij geen bezwaar, gegund aan de Inschrijver met de hoogste totaalscore f, de Top-1 Inschrijver. Voor de berekening van de kwaliteitsscore q en de totaalscore f zie paragraaf Vooraf zal een beschrijving van de PoC infrastructuur omgeving naar de betreffende Inschrijvers worden gestuurd. Bijlage 8.2 tot en met bijlage 8.4 bevat een beschrijving van de huidige infrastructuren. De PoC infrastructuur zal hiervan afgeleid zijn. De PoC omvat het verzorgen van een proefinstallatie, inclusief het beschikbaar stellen van de volledige pakketdocumentatie. De Inschrijver kan deze installatie deels thuis doen (bijv. door gebruik te maken van VMWare of MS Virtual Server images). Naast het installeren van de proefopstelling dient de Inschrijver tijdens de PoC één of meer demonstraties te geven voor belanghebbenden bij de Gemeenten. Hierbij zal het geoffreerde team door een beoordelingsteam worden geïnterviewd. Ook zal er een hands-on informatiemarkt worden georganiseerd, alwaar belanghebbenden zelf de Midoffice Suite zoals deze in de Proof of Concept is opgezet kunnen bedienen. Tevens is Inschrijver hier in de gelegenheid zich na de formele demonstraties te presenteren aan de potentiële gebruikers in de gemeenten. Deze informatiemarkt is dus niét verplicht. Europese aanbesteding , 28 maart

136 Hieronder is aangegeven wat het resultaat van de PoC moet zijn, uitgesplitst naar de verplicht te offreren elementen en de overige elementen. 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. Resultaat PoC Midoffice Suite Hieronder staan per onderdeel van de Midoffice Suite de gewenste projectresultaten van de Proof of Concept. Zie voor voorbeelden van de inrichting van de drie producten ook de specificaties van de Top-7 producten in paragraaf 8.7. 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 en vijf burgers ingericht. De Gemeenten verzorgen de NAW-gegevens en een DigiD-testaccount voor elke burger. - De beheersomgeving voor webintake, vraaggeleiding, workflow, documentbeheer, 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. - 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. Europese aanbesteding , 28 maart

137 - 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 ) 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: Evenementenvergunning Product Evenementenvergunning, een van de top-7 producten, dient volledig dik te worden ingericht. Hieronder wordt verstaan: - Een generieke applicatie waarmee een evenementenvergunning afgehandeld kan worden is gerealiseerd. - Productformulieren inclusief intelligentie, validaties en prefill zijn beschikbaar. - Het is mogelijk om binnen het formulier een locatie op te geven - Het is mogelijk om een bijlage met het formulier mee te sturen, welke vervolgens in het DMS wordt opgeslagen - Koppelingen met het gegevens- (synchronisatie) en zakenmagazijn (statusupdate) zijn gerealiseerd. - Proactieve en reactieve statusupdates kunnen automatisch naar de aanvrager worden verstuurd. - Voor 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. - De inrichting is zo veel mogelijk conform het formulier zoals opgenomen in paragraaf Als voorbeeld van de inrichting is in bijlage 8.16 de beschrijving opgenomen van de inrichting van de gemeente Dordrecht..Zie ook paragraaf 8.7 voor een beschrijving van de Top-7 producten. Product Verhuizing Product Verhuizing, een van de top-7 producten, dient volledig dun te worden ingericht. Hieronder wordt verstaan: - Productformulieren inclusief intelligentie, validaties en prefill zijn beschikbaar. Klanten kunnen attachments (zoals verklaringen) toevoegen. - Koppelingen met het gegevens- (synchronisatie) en zakenmagazijn (statusupdate) zijn gerealiseerd. - Transactie-, synchronisatie- en statuskoppeling met Procura testserver zijn gerealiseerd. - Proactieve en reactieve statusupdates kunnen automatisch naar de aanvrager worden verstuurd. Europese aanbesteding , 28 maart

138 - FO/KCC-medewerkers kunnen statussen inzien en wijzigen in het zakenmagazijn. - 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. - Zie ook paragraaf 8.7 voor een beschrijving van de Top-7 producten. Product Lichte bouwvergunning Op verzoek van de gemeente Utrecht is derde product te realiseren, welk dun en zonder WIS wordt uitgevoerd. Binnen dit optionele PoC-onderdeel ligt de nadruk op de integratie van de Broker met bestaande Frontoffice- en Backofficesystemen en de orkestratie van processen over deze systemen. De Inschrijver dient te laten zien hoe deze een dunne midoffice implementatie van het Bouwvergunningaanvraagproces realiseert binnen de architectuur van de gemeente waar de PoC wordt gehouden, waarbij m.b.v. de aangeboden Broker processen over FO- en BO-systemen georkestreerd worden. Hieronder wordt verstaan: - Er is een koppeling met de ICTU E-formulierenmachine - Koppelingen met zakenmagazijn (t.b.v. statusupdate) zijn gerealiseerd. - Transactie-, synchronisatie- en statuskoppeling met de BWT4all testserver zijn gerealiseerd. - Proactieve en reactieve statusupdates kunnen automatisch naar de aanvrager worden verstuurd. - FO/KCC-medewerkers kunnen statussen inzien in het zakenmagazijn. - Aanvragen kunnen worden doorgesluisd naar backoffice applicatie en statusinformatie over een specifieke zaak kan worden teruggestuurd naar of opgevraagd uit deze applicatie. - Het proces is als volgt gedefinieerd: o Bij de aanvraag van een bouwvergunning via webintake (via de ICTU e- formulieren site) wordt als eerste stap in de procesgang een verstuurd. De procesgang zoals deze in de broker is gedefinieerd wacht. o Nadat via een mail reply een fiat is gegeven wordt dit bericht terug gestuurd naar de Broker waarna het proces weer verder gaat. o De volgende stap in het proces is het sturen van een nieuw bericht naar de aanvrager. Dit terwijl de procesgang zoals deze in de Broker gedefinieerd is onverhinderd voort gaat en de bouwvergunningaanvraag in het BO-systeem start. - Zie ook paragraaf 8.7 voor een beschrijving van de Top-7 producten. Voor de Proof of Concept gelden de algemene voorwaarden in bijlage 1.1. Iedere Inschrijver dient zich akkoord te verklaren met de gestelde voorwaarden. Europese aanbesteding , 28 maart

139 8.7 Initiële implementatie: producten Ten behoeve van de Initiële implementatie zijn zeven gemeentelijke producten geselecteerd: 1. Aanvragen afschrift GBA 2. Aanvragen verhuizing (binnengemeentelijke én buitengemeentelijk) 3. Indienen melding openbaar gebied 4. Indienen generiek bezwaarschrift 5. Aanvragen evenementenvergunning (zie ook paragraaf 8.16) 6. Aanvragen gecombineerde BKS-vergunning (incl. super- en subzaken etc.) a. Lichte bouwvergunning b. Kapvergunning c. Sloopvergunning 7. Intern: in- en uitdiensttreding 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 front- en 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. Deze kan per gemeente verschillen. 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. Europese aanbesteding , 28 maart

140 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 backoffice applicatie naar het zakenmagazijn). De gemeenten in het Consortium hebben de uitdrukkelijke intentie om voor de producten uit de Initiële implementatie naast synchronisatie- en statuskoppelingen indien van toepassing ook transactiekoppelingen te realiseren. Volgens het fasemodel elektronische dienstverlening (zie figuur 8.1) heeft dergelijke transactie integratie betrekking op fase 3. Overigens lenen niet alle gemeentelijke producten zich daadwerkelijk voor elektronische levering (fase 4). Fase Publicatie Intake Verwerking Levering Fase 0 Papieren formulier Handmatig (papier) Handmatig (papier) Handmatig (papier) Fase 1 Printformulier (PDF / Word) Handmatig (papier) Handmatig (papier) Handmatig (papier) Fase 2 E-formulier Elektronisch Handmatig (papier) Handmatig (papier) Fase 3 E-formulier Elektronisch Elektronisch Handmatig (papier) Fase 4 E-formulier Elektronisch Elektronisch Elektronisch Figuur 8.1: 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 = weergave van geografische gegevens en / of het op een kaart aanwijzen van een locatie Aanvragen afschrift GBA - PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden - DigiD: ja Europese aanbesteding , 28 maart

141 - GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) - GM: adresgegevens uit (basis)adressenregistratie - GEO: - Bijlagen: evt (bewijsstukken waarom men in aanmerking komt voor gratis verstrekking) - Betalen: ja - Overige: documentsjabloon (het uittreksel waarop de gegevens worden ingevuld) - Zie ook paragraaf Verhuizing (binnengemeentelijk én buitengemeentelijk) - PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden - DigiD: optioneel (alleen bij binnengemeentelijke verhuizing) - 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 (huurcontract, toestemming hoofdbewoner, etc) - Betalen: eventueel - Overige: - Zie ook paragraaf Indienen melding openbaar gebied - PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden - DigiD: optioneel - GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) - GM: adresgegevens uit (basis)adressenregistratie - GEO: ja (aanwijzen van de locatie) - Bijlagen: eventueel (foto s, andere bewijsstukken) - Betalen: nee - Overige: naar klantprofiel ( + telefoonnummer ten behoeve van terugmelding) - Zie ook paragraaf Indienen generiek bezwaarschrift - 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 en ZM: gegevens en processen waarover bezwaar wordt gemaakt - GEO: eventueel, aanwijzen locatie - Bijlagen: evt (bewijsstukken) - Betalen: nee - Overige: - Zie ook paragraaf Europese aanbesteding , 28 maart

142 Aanvragen evenementenvergunning - PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden - DigiD: eventueel (ook bedrijven) - GM: persoonsgegevens uit GBA ten behoeve van DigiD en prefill of ter controle van de verstrekte gegevens (zomogelijk) - GM: adresgegevens uit (basis)adressenregistratie - GEO: ja (locatie aanwijzen op kaart) - Bijlagen: ja (bewijsstukken) - Betalen: ja - Overige: - Zie ook paragraaf en paragraaf 8.7 Aanvragen gecombineerde BKS-vergunning - PDC: vier beschrijvingen product (volledige product en deelproducten) 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: ja, aanwijzen locatie - Bijlagen: evt (bewijsstukken) - Betalen: ja - Overige: bestaat uit drie subzaken: Lichte bouwvergunning, Kapvergunning en Sloopvergunning. De BKS-vergunning is een soort kleine omgevingsvergunning en omvat een super-zaak, een super-proces, een super-formulier, etc. met subzaken, sub (afhandeling)processen, subformulieren (met een gedeeld super formulier), etc. - Zie ook paragraaf Intern: in- en uitdiensttreding - PDC: beschrijving product inclusief procedure en eisen / randvoorwaarden (alleen beschikbaar voor intern) - DigiD: nee - GM: nee - GEO: nee - Bijlagen: eventueel - Betalen: nee - Overige: intern product, dit betreft het attenderen en informeren van alle relevante afdelingen en personen. Koppelingen met alle verschillende systemen waar medewerkergegevens staan is niet vereist. - Zie ook paragraaf Europese aanbesteding , 28 maart

143 8.8 Top-34 producten Onderstaand volgt een lijst van 34 gemeentelijke producten. Het betreft hier een lijst van producten/processen die is opgesteld in het kader van het Programma Ander Overheid (PAO). Voor burgers Inzameling huisvuil Heffing rioolrecht Afvalstoffenheffing Inzage bestemmingsplannen Aanvraag inzameling grofvuil Aanvraag GBA-uittreksel Doorgeven verhuizing Aanvraag kwijtschelding belasting/heffing Aanvraag aankoop/verhuur bouwgrond Onroerende Zaak Belasting (OZB) Indienen bezwaarschrift Melding schade/onderhoud openbare wegen Melding schade/onderhoud openbaar groen Aanvraag evenementenvergunning Aanvraag parkeervergunning Aanvraag bouwvergunning Aanvraag kapvergunning Aanvraag paspoort Aanvraag rijbewijs Aanvraag Wet Voorzieningen Gehandicapten Aanvraag verklaring inkomen en vermogen Aanvraag (bijzondere) bijstand Voor bedrijven Inzameling bedrijfsafval Heffing rioolrecht Afvalstoffenheffing Inzage bestemmingsplannen Aanvraag aankoop/verhuur bedrijfsterrein Onroerende Zaak Belasting (OZB) Indienen bezwaarschrift Aanvraag evenementenvergunning Aanvraag in/uitritvergunning Aanvraag parkeervergunning Aanvraag milieuvergunning Aanvraag bouwvergunning Europese aanbesteding , 28 maart

144 8.9 Controlelijst eisen In de controlelijst eisen (tabel 8-1) 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. 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 Akkoord (ja/nee) Behandeld (ja/nee) Toelichting Europese aanbesteding , 28 maart

145 Nr. E30 E31 E32 E33 E34 E35 E36 E37 E38 E39 E40 E41 E42 E43 E44 Akkoord (ja/nee) Behandeld (ja/nee) Tabel 8-1: controlelijst eisen Toelichting Europese aanbesteding , 28 maart

146 8.10 Controlelijst vragen en functionaliteiten Tabel 8-2 bevat de controlelijst vragen en functionaliteiten. Inschrijver dient deze in te vullen. De kolom Behandeld (ja/nee) is een controlemiddel voor de Inschrijver of alle vragen zijn beantwoord. In de kolom Maatwerk (ja/nee) dient u aan te geven of er maatwerk nodig is om alle functionaliteit te realiseren die in het antwoord op de betreffende vraag door de Inschrijver wordt genoemd. In de kolom Toelichting kan een korte toelichting worden opgenomen. In de kolom Applicaties, modules. etc. dient u aan te geven welke applicaties (inclusief koppelingen, add-ons, maatwerksoftware, etc.) of diensten nodig zijn om alle functionaliteit die in het antwoord op de betreffende vraag door de Inschrijver wordt genoemd te realiseren. Met de in deze kolom genoemde applicaties (inclusief koppelingen, add-ons, maatwerksoftware, etc.) en diensten dient alle functionaliteit die in de antwoorden op de vragen door de Inschrijver wordt genoemd te kunnen worden gerealiseerd. Al deze onderdelen dienen dmv. het prijssjabloon (zie ook hoofdstuk 6) te zijn geoffreerd. Indien blijkt dat dit niet geval is zal voor het bepalen van de f-score (zie paragraaf 2.5.4) de prijs van de ontbrekende onderdelen gelijk worden gesteld aan een door de Gemeenten nog in redelijkheid te bepalen forfaitbedrag. Nr. Behandeld (ja/nee) Maatwerk (ja/nee) Applicaties, modules. etc. (naam + versie + uitvoering (Enterprise, Basic, etc)) V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11 V12 V13 V14 V15 V16 V17 V18 V19 V20 V21 V22 V23 # 41 V24 Toelichting 41 Zie paragraaf voor betekenis van de # Europese aanbesteding , 28 maart

147 Nr. 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 V58 V59 V60 V61 V62 V63 V64 V65 V66 V67 V68 V69 V70 Behandeld (ja/nee) Maatwerk (ja/nee) Applicaties, modules. etc. (naam + versie + uitvoering (Enterprise, Basic, etc)) Toelichting Europese aanbesteding , 28 maart

148 Nr. Behandeld (ja/nee) Maatwerk (ja/nee) 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 V101 V102 V103 nvt nvt Applicaties, modules. etc. (naam + versie + uitvoering (Enterprise, Basic, etc)) Tabel 8-2: controlelijst vragen en functionaliteiten Toelichting Europese aanbesteding , 28 maart

149 8.11 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 de aanbestedende diensten aannemelijk kunnen maken; - Hij niet aan zijn verplichtingen heeft voldaan ten aanzien van de betaling van de sociale zekerheidsbijdragen 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. - Jegens hem bij een onherroepelijk vonnis of arrest een veroordeling is uitgesproken op grond van artikel 140, 177, 177a, 178, 225, 226, 227, 227a, 227b of 323a, 328ter, tweede lid, 416, 417, 417bis, 420bis, 420ter of 420quater van het Wetboek van Strafrecht. Inschrijver verklaart, dat hij deze verklaring naar waarheid heeft ondertekend. Plaats: Datum: Naam: Functie: Handtekening: Europese aanbesteding , 28 maart

150 8.12 Conceptovereenkomst Europese aanbesteding , 28 maart

151 Gemeente concept v1.0 Overeenkomst Midoffice Suite De ondergetekenden, <gemeente>, ten deze vertegenwoordigd door <vertegenwoordigingsbevoegde, functie>, hierna te noemen: Gemeente en <naam>, ten deze rechtsgeldig vertegenwoordigd door <vertegenwoordigingsbevoegde functionaris, functie>, hierna te noemen: (initiële) Implementatiepartner, gezamenlijk te noemen: Partijen, ieder apart te noemen: Partij Considerans overwegende dat: 1. Gemeente op <datum> middels de Europese aanbesteding <ref> een Offerte heeft gevraagd ten behoeve van het ter beschikking stellen van een Midoffice Suite met de doelstelling de dienstverlening aan burgers en bedrijven door Gemeente te verbeteren; 2. Implementatiepartner op <datum> een Offerte heeft uitgebracht voor de installatie en initiële implementatie van een Midoffice Suite; 3. (optioneel) Implementatiepartner op <datum> en <datum> schriftelijke aanvullingen op de uitgebrachte Offerte heeft gedaan; 4. Implementatiepartner bereid en in staat is deze Midoffice Suite te installeren, te implementeren en op basis van een SNO te onderhouden, onder meer ten behoeve van de hiervoor genoemde doelstelling; 5. dat Gemeente deze opdracht aan Implementatiepartner wenst te gunnen; 6. dat Partijen hun contractuele relatie voor deze opdracht voor een periode van minimaal drie jaren wensen vast te leggen; 7. dat Gemeente ten behoeve van de hiervoor aangegeven installatie, implementatie- en onderhoudsdiensten gebruik wenst te maken van het aanbod van Implementatiepartner; 8. Partijen hiertoe een resultaatsverbintenis zullen aangaan onder de voorwaarden van deze Overeenkomst; verklaren te zijn overeengekomen als volgt: 151 Paraaf Gemeente: Paraaf Implementatiepartner:

152 Gemeente concept v1.0 Inhoudsopgave Artikel 1: Begrippen 153 Artikel 2: Onderwerp 154 Artikel 3: Vertegenwoordiging, projectleiding, (voortgangs-)rapportage en overleg 155 Artikel 4: Aanvang werkzaamheden; duur van de Overeenkomst 156 Artikel 5: Wijzigingen van de Overeenkomst 156 Artikel 6: Oplevering en Acceptatie 156 Artikel 7: Garantie 157 Artikel 8: Onderhoud 159 Artikel 9: <Licentie><Voortdurende Licentie> 159 Artikel 10: Aansprakelijkheid 160 Artikel 11: Prijzen 161 Artikel 12: Betaling 162 Artikel 13: Intellectuele (eigendoms)rechten 162 Artikel 14: Geheimhouding en beveiliging 163 Artikel 15: Verzekering 164 Artikel 16: Ondersteuning 164 Artikel 17: Documentatie 164 Artikel 18: Niet toerekenbare tekortkoming (overmacht) 165 Artikel 19: Ontbinding 165 Artikel 20: Overdracht rechten en verplichtingen; onderaanneming 165 Artikel 21: Geschillen en toepasselijk recht 166 Artikel 22: Algemeen Paraaf Gemeente: Paraaf Implementatiepartner:

153 Gemeente concept v1.0 Artikel 1: Begrippen 1.1 Acceptatie: het door Gemeente goedkeuren van het overeengekomen deel van het Resultaat. 1.2 Acceptatieplan: document waarin is vastgelegd op welke wijze Gemeente, na consultatie van Implementatiepartner, de juistheid van het Resultaat vaststelt. 1.3 Bijlage: een aanhangsel bij deze Overeenkomst die, nadat deze door Partijen is geparafeerd, onderdeel uitmaakt van deze Overeenkomst. 1.4 Documentatie: de beschrijving van de Midoffice Suite ten behoeve van Gemeente en bestemd voor de installatie en het gebruik van de Midoffice Suite binnen de organisatie van Gemeente en met inbegrip, maar niet beperkt tot, documentatie op voor computer leesbare media. De documentatie is zowel gericht op beheer van de Midoffice Suite door (technisch) IT personeel, als op dagelijks operationeel gebruik. 1.5 Gebrek: tekortkomingen aan het Resultaat, zoals verwoord in de sub 2.3 bedoelde documenten, dan wel het vanuit technische optiek niet naar behoren functioneren van de Midoffice Suite. 1.6 Klein Gebrek: Tekortkomingen in het Resultaat van zodanige aard, aantal en/of omvang dat ze niet aan Acceptatie in de weg staan maar, in welke vorm dan ook, wel leiden tot een voor Gemeente verminderd gebruiksgemak. 1.7 Licentie: het recht van Gemeente de Midoffice Suite (met inbegrip van mogelijke Nieuwe Versies) conform de bepalingen van deze Overeenkomst te gebruiken. 1.8 Materialen: alle voor het gebruik, installatie en wijziging van de Midoffice Suite benodigde hulpmaterialen, zoals media, compilers, etc. 1.9 Midoffice Suite: de door Implementatiepartner in het kader van deze Overeenkomst beschikbaar te stellen software zoals beschreven in Bijlage D met bijbehorende centrale toegangscode (key) en Documentatie waarvoor Implementatiepartner middels deze Overeenkomst aan Gemeente een <Licentie><Voortdurende Licentie> verleent en die door Implementatiepartner in het kader van deze Overeenkomst geschikt wordt gemaakt en gehouden voor de in de considerans beschreven doelstelling Nieuwe Versie: een gewijzigde c.q. opvolgende versie van de Midoffice Suite, waardoor de functionaliteit daarvan, al of niet op verzoek van Gemeente, wordt vergroot. Een Nieuwe Versie kan naar keuze van Implementatiepartner met een gewijzigde benaming worden aangeboden Offerte: alle documenten die Implementatiepartner aan Gemeente heeft aangeboden ter beantwoording van het gestelde in de Europese aanbestedingsprocedure en in het bijbehorende Programma van Eisen Onderhoud: alle door Implementatiepartner op basis van deze Overeenkomst en de SNO te verrichten activiteiten die nodig zijn voor het waarborgen van de functionaliteit en ononderbroken goede werking van de Midoffice Suite Oplevering: het aanbieden door Implementatiepartner van het Resultaat ter Acceptatie door de Gemeente Overeenkomst: de onderhavige overeenkomst met Bijlagen Personeel: de door Partijen voor de uitvoering van deze Overeenkomst ter beschikking te stellen personeelsleden en/of hulppersonen, welke krachtens deze Overeenkomst werkzaamheden zullen verrichten Programma van Eisen: het geheel van kwantitatieve en/of functionele en/of technische eisen en/of wensen zoals door Gemeente is verwoord als onderdeel van het bestek in het kader van de Europese aanbesteding <ref> op basis waarvan Implementatiepartner zijn Offerte heeft uitgebracht. 153 Paraaf Gemeente: Paraaf Implementatiepartner:

154 Gemeente concept v Projectplan: de door Implementatiepartner nader uitgewerkte en door Gemeente goedgekeurde versie van het plan van aanpak uit de Offerte, die vervolgens als Bijlage bij deze Overeenkomst wordt gevoegd. Het test- en acceptatieplan maakt tevens deel uit van het Projectplan Resultaat: de door Partijen overeengekomen prestaties in het kader van de te verrichten implementatiewerkzaamheden gericht op een werkende totaaloplossing als bedoeld in het Programma van Eisen, welke prestaties door Implementatiepartner aan Gemeente ter goedkeuring door Gemeente wordt opgeleverd zoals en voor zover deze als op te leveren en goed te keuren zijn gespecificeerd in of bij deze Overeenkomst. De in het Programma van Eisen beschreven (i) installatie en basisimplementatie, (ii) het inrichten van de Top-7 en de migratie en (iii) Top-34 (optioneel)vormen ieder een overeengekomen deel van het Resultaat SNO: Service Niveau Overeenkomst, de door Implementatiepartner nader uitgewerkte en door Gemeente goedgekeurde versie van het SNO, bevattende het geheel van operationele afspraken op basis waarvan Implementatiepartner het Onderhoud uitvoert Systeem: het geheel van (operating system en database)programmatuur en serverapparatuur van Gemeente in combinatie waarmee de Midoffice Suite door Implementatiepartner wordt geïmplementeerd en onderhouden Verbeterde Versie: een gewijzigde versie van de Midoffice Suite, waardoor Gebreken worden hersteld, of de logische samenhang wordt verbeterd Voortdurende Licentie: de Licentie waarbij sprake is van een eeuwigdurend en onherroepelijk gebruiksrecht Werkdagen: kalenderdagen, behoudens weekenden, algemeen erkende feestdagen en voor Personeel van Gemeente verplichte vrije dagen tussen feestdagen (brugdagen). Artikel 2: Onderwerp 2.1 De considerans van deze Overeenkomst maakt onderdeel uit van de Overeenkomst. 2.2 Implementatiepartner zal het Resultaat opleveren. Implementatiepartner verleent vervolgens en verklaart hiertoe bevoegd te zijn, Gemeente een niet exclusieve en niet overdraagbare <Licentie> < Voortdurende Licentie> om de in de Bijlage D verbijzonderde en vermelde hoeveelheid van de Midoffice Suite te gebruiken waarvoor de overeengekomen vergoedingen zijn betaald. Implementatiepartner draagt aan Gemeente het eigendom over van de Materialen waarop de Midoffice Suite is vastgelegd. De hiervoor geldende vergoeding wordt geacht in de vergoeding(en) voor de <Licentie><Voortdurende Licentie> te zijn begrepen. Implementatiepartner levert tevens het Onderhoud op basis van de in Bijlage E benoemde Service Niveau Overeenkomst. Als tegenprestatie betaalt Gemeente de vergoeding(en) conform het bepaalde in artikel De navolgende bescheiden maken deel uit van de Overeenkomst. 1. Aanvaarding van wijzigingsspecificaties volgens artikel 5.3, deze worden gevoegd als Bijlage A; 2. het door Gemeente goedgekeurde Projectplan (Bijlage B); 3. het Programma van Eisen, zoals te vinden in het Bestek (Bijlage C); 4. de door Implementatiepartner in het kader van de Europese Aanbesteding uitgebracht Offerte, met inbegrip van alle bijbehorende bijlagen (Bijlage D); 5. De tussen Partijen vastgestelde geldende Service Niveau Overeenkomst (Bijlage E) 2.4 Bij strijdigheid van de bepalingen uit deze Overeenkomst en de inhoud van de Bijlagen prevaleren de bepalingen van deze Overeenkomst. Bij strijdigheid van de bepalingen van de Bijlagen onderling prevaleren de bepalingen van de Bijlage die het hoogst in rangorde is opgesomd. 154 Paraaf Gemeente: Paraaf Implementatiepartner:

155 Gemeente concept v Implementatiepartner heeft zich in voldoende mate op de hoogte gesteld van de doelstellingen van Gemeente met betrekking tot de onderhavige Overeenkomst, vooral in kader van de taak van Gemeente in relatie met burgers, bedrijven, ketenpartners en medewerkers. Gemeente heeft Implementatiepartner daartoe middels het Programma van Eisen van voldoende en correcte informatie voorzien, en zal Implementatiepartner de verdere noodzakelijke informatie verstrekken, voor zover die informatie bij Gemeente beschikbaar is. 2.6 Ter zake van de uitvoering van deze Overeenkomst worden door Partijen de in het Projectplan genoemde Personeelsleden ingezet, met achter hun naam vermelding van hun functie en, in het geval van Personeel van Implementatiepartner, het uurtarief, alsmede de werkzaamheden waarvoor zij worden ingezet. Implementatiepartner houdt overigens voldoende, gekwalificeerd Personeel beschikbaar om deze Overeenkomst te kunnen uitvoeren. Van Personeel dat Implementatiepartner inzet voor de uitvoering van de SNO ontvangt Gemeente opgave van die gegevens die noodzakelijk zijn voor de toepassing van de code voor Informatiebeveiliging. Artikel 3: Vertegenwoordiging, projectleiding, (voortgangs-)rapportage en overleg 3.1 Door Implementatiepartner is als projectmanager voor de gehele duur van de uitvoering van de werkzaamheden aangewezen <functionaris>. Voor Gemeente is dit <functionaris>. De projectmanager vanwege Implementatiepartner is verantwoordelijk voor het behalen van het Resultaat en voor de continuïteit en de voortgang van de werkzaamheden. De projectmanager vanwege Gemeente biedt daarbij een zo goed mogelijke ondersteuning vanuit de positie en rol van Gemeente. Ondersteuning door de projectmanager vanwege de Gemeente loopt niet vooruit op formele besluitvorming door Gemeente sub 3.3 bedoeld. De projectmanagers zullen omtrent de voortgang en hun bevindingen rapporteren op de wijze in artikel 3.4 genoemd. De projectmanagers, de projectgroep en de contactpersonen in artikel 3.3 bedoeld zijn verplicht elkaar alle door hen gewenste inlichtingen te verstrekken 3.2 De taken van de projectmanager van Implementatiepartner zijn in het Projectplan nader uitgewerkt maar omvatten in ieder geval de navolgende: - organisatie en coördinatie van de werkzaamheden die ten behoeve van de in artikel 2 omschreven prestatie(-s) dienen te worden verricht; - het opstellen van detailplanningen, waaronder een migratieplan en een test- en Acceptatieplan; - het stimuleren en bewaken van de voortgang van de werkzaamheden, getoetst aan het Projectplan; - het doen van voorstellen voor beslissingen welke door de contactpersonen dienen te worden genomen. De projectmanager van Implementatiepartner is tevens aanspreekpunt voor de informatiebeveiligingsmaatregel aan de zijde van Implementatiepartner. 3.3 Vertegenwoordigingsbevoegdheid. Beide Partijen hebben een contactpersoon en een vervangend contactpersoon aangewezen, anders dan de projectmanager, die de formele contacten (w.o. juridische en commerciële) over de wijze van uitvoering van deze Overeenkomst, de wijzigingen zoals in artikel 5 bedoeld daaronder begrepen, zullen onderhouden. Voor Gemeente is dit <vertegenwoordigingsbevoegde functionaris>. Voor Implementatiepartner is dit <vertegenwoordigingsbevoegde functionaris>. Zonder voorafgaande instemming van Gemeente, zal Implementatiepartner haar contactpersoon niet vervangen. Instemming zal niet op onredelijke gronden worden geweigerd. Deze contactpersonen zijn bevoegd de Partij die hen heeft aangewezen, in het kader van de uitvoering van deze Overeenkomst te vertegenwoordigen en te binden. 3.4 Implementatiepartner verstrekt Gemeente in een projectgroep, welke door Gemeente uit Personeel van beide Partijen is samengesteld, informatie over de voortgang van de werkzaamheden. De projectmanager van <Gemeente> is voorzitter van de projectgroep. Van deze besprekingen worden door Gemeente notulen opgesteld. Deze notulen worden telkenmale op de volgende projectgroepbijeenkomst doch uiterlijk binnen twee werkdagen na de betreffende bijeenkomst door Partijen goedgekeurd. De onder artikel 3.3 genoemde contactpersonen maken van deze projectgroep deel uit. 155 Paraaf Gemeente: Paraaf Implementatiepartner:

156 Gemeente concept v Indien Partijen geen overeenstemming kunnen bereiken over de formulering van hetgeen in de projectgroep aan de orde is gekomen, wordt dit verschil van mening in de notulen vastgelegd alvorens te worden geëscaleerd op de in het Projectplan aangegeven wijze. 3.6 Afspraken die in goedgekeurde notulen zijn vastgelegd zijn, mits bevoegdelijk door de contactpersonen of hun vervangers aangegaan, voor beide Partijen bindend. 3.7 Indien de voortgang van de werkzaamheden vertraging dreigt te gaan ondervinden c.q. heeft ondervonden, zal Implementatiepartner hiervan zo spoedig mogelijk, doch uiterlijk binnen vijf Werkdagen, schriftelijk door middel van een rapportage aan Gemeente melding maken en daarbij aangeven de oorzaak van de vertraging, alsmede de door Implementatiepartner voorgestelde maatregelen om de dreigende vertraging te voorkomen of ongedaan te maken. Tevens zullen de consequenties van deze vertraging in de rapportage worden vermeld. Het in ontvangst nemen door Gemeente van de rapportage houdt niet in dat Gemeente de oorzaak van de vertraging erkent of gehoudenheid tot vergoeding van daaruit voortvloeiende consequenties erkent, dan wel formeel van vorderingen afziet. Artikel 4: Aanvang werkzaamheden; duur van de Overeenkomst 4.1 Deze Overeenkomst wordt aangegaan voor een periode van drie jaar, gaat in op <datum> en eindigt derhalve per <datum>. Na afloop van deze periode wordt deze Overeenkomst steeds stilzwijgend met een periode van één jaar verlengd, met een maximum van twee jaar, tenzij Gemeente uiterlijk drie maanden voor afloop van de betreffende periode schriftelijk aangeeft de Overeenkomst te willen beëindigen. Artikel 5: Wijzigingen van de Overeenkomst 5.1 Gemeente is te allen tijde gerechtigd de aard en omvang van de door Implementatiepartner op grond van deze Overeenkomst te verrichten werkzaamheden, in redelijkheid te wijzigen, echter niet dan na tussenkomst door de sub 3.3 genoemde contactpersonen. 5.2 Implementatiepartner specificeert binnen vijf (5) werkdagen na ontvangst van een dergelijke wijzigingsinstructie schriftelijk welke kwantitatieve en kwalitatieve consequenties de wijziging heeft met betrekking tot in te zetten Personeelsleden, de te verwachten uitbreiding c.q. vermindering van de te besteden uren per Personeelslid, de prijs, planning en Oplevering. Gemeente is gerechtigd, tot twee werkdagen na ontvangst van deze specificatie, de wijzigingsopdracht alsnog in te trekken c.q. te modificeren. 5.3 Wijzigingen van de Overeenkomst gelden vanaf het moment van schriftelijke aanvaarding door Gemeente van de onder 5.2. genoemde specificatie, welke documenten als Bijlage bij deze Overeenkomst zullen worden gevoegd. Artikel 6: Oplevering en Acceptatie 6.1 Implementatiepartner stelt de contactpersoon van de Gemeente schriftelijk op de hoogte van de (aankomende) Oplevering van het overeengekomen deel van het Resultaat. De Oplevering geschiedt op de overeengekomen datum zoals in het Projectplan is bepaald. Indien Implementatiepartner verzuimt in de nakoming van zijn verplichting tot Oplevering op de overeengekomen datum verbeurt hij, zonder dat enige aanmaning of ingebrekestelling is vereist, een dadelijk opeisbare boete aan Gemeente van 1.000,00 per werkdag of gedeelte van een werkdag dat het verzuim voortduurt, een en ander tot een maximum van ,00. De boete laat de overige rechten van Gemeente, waaronder die op schadevergoeding en/of volledige nakoming, onverlet. 156 Paraaf Gemeente: Paraaf Implementatiepartner:

157 Gemeente concept v Ten behoeve van de formele Acceptatie van het overeengekomen deel van het Resultaat stelt Implementatiepartner een concept Acceptatieplan op, dat door Gemeente - al dan niet na wijziging - tot definitief bij de formele acceptatie te hanteren document wordt vastgesteld. 6.3 In overleg bepalen Partijen een datum voor de Acceptatie. Gemeente onderwerpt het door Implementatiepartner opgeleverde overeengekomen deel van het Resultaat ten behoeve van de Acceptatie aan de in het Acceptatieplan beschreven goedkeuringsprocedure. De goedkeuringsprocedure betreft zowel het overeengekomen deel van het Resultaat als de bijbehorende Documentatie. In het kader van de goedkeuringsprocedure is Gemeente gerechtigd te verlangen dat Implementatiepartner het overeengekomen deel van het Resultaat aan Gemeente, diens personeel, alsmede aan derde deskundigen demonstreert alvorens Gemeente het Resultaat accepteert. 6.4 Gemeente is gerechtigd na voorafgaande schriftelijke kennisgeving het overeengekomen deel van het Resultaat door een (onafhankelijke) derde deskundige, ter verkrijging van een Third Party Mededeling conform het Voorschrift Informatiebeveiliging Rijksdienst (VIR), te laten onderzoeken, alvorens het overeengekomen deel van het Resultaat te accepteren. Implementatiepartner is verplicht hieraan zijn medewerking te verlenen, maar kan verlangen dat de derde deskundige vooraf verklaart, zich te zullen houden aan de verplichting tot geheimhouding. 6.5 Direct nadat de goedkeuringsprocedure is doorlopen wordt door Gemeente een verslag opgesteld en aan Implementatiepartner toegezonden. In dit verslag worden de Gebreken die het overeengekomen deel van het Resultaat vertoont vastgelegd en voorts of het overeengekomen deel van het Resultaat door Gemeente is goedgekeurd, dan wel afgekeurd. Kleine Gebreken zullen geen reden tot onthouding van de goedkeuring zijn, onverminderd de verplichting van Implementatiepartner tot kosteloos herstel van Kleine Gebreken. Binnen een door Gemeente te stellen redelijke termijn na de datum van het verslag zal Implementatiepartner de in het verslag vastgelegde Gebreken voor eigen rekening verhelpen. 6.6 Indien Gemeente het overeengekomen deel van het Resultaat niet bij eerste uitvoering van de goedkeuringsprocedure sub 6.3 heeft goedgekeurd, wordt de goedkeuringsprocedure binnen een door Gemeente te stellen redelijke termijn geheel of gedeeltelijk herhaald. In een aanvullend verslag zal worden vastgelegd of de in het eerste verslag opgenomen Gebreken zijn verholpen en of het overeengekomen deel van het Resultaat thans wordt geaccepteerd. 6.7 Indien het overeengekomen deel van het Resultaat na de tweede goedkeuringsprocedure sub 6.6 opnieuw door Gemeente wordt afgekeurd, is Gemeente gerechtigd deze Overeenkomst buiten rechte te ontbinden zonder dat daarvoor enige aanmaning of ingebrekestelling is vereist. 6.8 Indien alle onderdelen van het overeengekomen deel van het Resultaat door Gemeente worden goedgekeurd, onverkort het gestelde omtrent Kleine Gebreken, geldt de datum waarop het verslag als bedoeld in artikel 6.5 is opgesteld en door Partijen is ondertekend, als datum van Acceptatie. 6.9 Indien Implementatiepartner niet tijdig voldoet aan zijn verplichting tot herstel van Gebreken is Gemeente, onverminderd haar verdere rechten, gerechtigd deze Gebreken na voorafgaande schriftelijke kennisgeving op kosten van Implementatiepartner hetzij zelf, hetzij door derden te doen verhelpen. Implementatiepartner is verplicht hieraan zijn medewerking te verlenen. Implementatiepartner is in dat geval verplicht de daarvoor benodigde informatie op eerste verzoek te verstrekken. Artikel 7: Garantie 7.1 Implementatiepartner garandeert dat het door hem op te leveren overeengekomen deel van het Resultaat gedurende zes maanden voldoet aan de overeengekomen kwalificaties en specificaties als vastgelegd in de artikel 2.3 bedoelde documenten en aan de binnen de betreffende beroepsgroep gebruikelijke kwaliteitseisen en standaarden. 7.2 Implementatiepartner garandeert gedurende de looptijd van de Overeenkomst dat: 157 Paraaf Gemeente: Paraaf Implementatiepartner:

158 Gemeente concept v Nieuwe c.q. Verbeterde Versies minimaal de functionele en technische eigenschappen hebben, die de Midoffice Suite bij Acceptatie bevat; de Midoffice Suite door hem met zodanige aanpassing geschikt gemaakt kan worden dat deze niet tot een verminderd gebruiksgemak of functionaliteit lijdt indien zij wordt geïnstalleerd op of in samenhang met opvolgende versies van standaard operating systems en databaseprogrammatuur van het Systeem en overige hierop geïnstalleerde c.q. daarmee samenwerkende standaardprogrammatuur, voor zover deze bij het sluiten van deze Overeenkomst bij Implementatiepartner bekend was c.q. redelijkerwijs bekend kon zijn, waarop of in samenhang waarmee de Midoffice Suite dient te werken; hij gebruikservaringen met betrekking tot de Midoffice Suite zal inventariseren, voortdurend onderzoek en ontwikkeling ten aanzien van de Midoffice Suite zal blijven uitvoeren en, door middel van Nieuwe en/of Verbeterde Versies wijzigingen of aanvullingen van de programmatuur direct na het tot stand komen daarvan steeds aan Gemeente zal aanbieden in het kader van de levering van Onderhoud. 7.3 Indien Gemeente tijdens de garantieperiode op enig tijdstip constateert dat de Midoffice Suite niet voldoet aan de garantiebepalingen, stelt Gemeente Implementatiepartner hiervan schriftelijk, en in spoedgevallen telefonisch, op de hoogte, waarna Implementatiepartner de verplichting heeft het Gebrek kosteloos te verhelpen overeenkomstig de bepalingen van het SNO c.q. verplicht is om kosteloos een aanvullende Licentie te verstrekken of anderszins kosteloos te voldoen aan de uit de garantie voortvloeiende verplichtingen. Gemeente heeft steeds aanspraak op de rechten uit de garantie, waartoe Gemeente slechts behoeft aan te tonen dat de Midoffice Suite de gegarandeerde eigenschap(pen) niet bevat, c.q. niet naar behoren functioneert. 7.4 Implementatiepartner levert, indien de Midoffice Suite in het kader van sub 7.1 en/of 7.2 niet of niet geheel goed functioneert in samenhang met het Systeem, ondersteuning en werkt actief mee met andere betrokken leveranciers tot het probleem is opgelost. De kosten van dit onderzoek en deze samenwerking zijn voor rekening van Implementatiepartner, tenzij Implementatiepartner onomstotelijk aantoont dat een derde Partij of de Gemeente deze kosten dient te dragen. 7.5 Indien Implementatiepartner van mening is dat Gemeente geen beroep kan doen op de garantiebepalingen, omdat een Gebrek niet behoort tot de gegarandeerde eigenschappen, rust de bewijslast ter zake bij Implementatiepartner. 7.6 Het bepaalde sub 7.1 en 7.2 vervalt indien en voor zover door Gemeente zonder de ingevolge deze Overeenkomst verkregen of nader verkregen toestemming van Implementatiepartner wijzigingen in de Midoffice Suite zijn aangebracht, tenzij Gemeente aantoont dat het Gebrek niet door de wijzigingen is ontstaan c.q. het Gebrek ook zonder de wijzigingen zou zijn ontstaan. Indien het voor de uitvoering van de garantieverplichtingen noodzakelijk is dat Implementatiepartner het Systeem (op afstand) met eigen apparatuur verbindt, dan wel eigen programma's op het Systeem installeert met het oogmerk Gebreken op te sporen respectievelijk gedragingen van de Midoffice Suite vast te leggen, zal Gemeente dit gedogen, tenzij dit uit beveiligings- en/ of continuïteitsoverwegingen in redelijkheid niet van Gemeente kan worden gevergd, zulks ter beoordeling van Gemeente. Implementatiepartner is gehouden om Gemeente vooraf gedetailleerd te informeren over de consequenties van het gebruik van de hiervoor bedoelde middelen voor Gemeente. Gemeente is gerechtigd aan deze verbindingen of installatie informatiebeveiligingseisen te stellen zoals versleuteling of logging of het geheel dan wel gedeeltelijk verwijderen van gegevens. De kosten van deze inzet van verbindingsmiddelen en van de informatiebeveiligingsmiddelen zijn voor rekening van Implementatiepartner. 7.7 Implementatie garandeert dat hij bij naamsverandering van (delen van) de Midoffice Suite of het herbundelen van (delen van) producten waaruit de Midoffice Suite bestaat kosteloos het recht van eventueel hieruit voortvloeiende functionaliteiten zal verstrekken en dat deze wijzigingen geen nadelige consequenties zullen hebben voor prijs en inhoud van Licenties en Onderhoud. 158 Paraaf Gemeente: Paraaf Implementatiepartner:

159 Gemeente concept v1.0 Artikel 8: Onderhoud 8.1 Het Onderhoud gaat in na afloop van de sub 7.1 genoemde garantieperiode en wordt uitgevoerd op basis van de tussen Partijen overeengekomen SNO. De SNO heeft een looptijd van minimaal één jaar en wordt steeds stilzwijgend met één jaar verlengd, tenzij de Gemeente drie maanden voor afloop van de betreffende looptijd aangeeft de SNO te willen beëindigen. De SNO eindigt te allen tijde met het eindigen van deze Overeenkomst. 8.2 Het Onderhoud bestaat uit de levering van Verbeterde en Nieuwe Versies en het herstel van Gebreken, een en ander op de wijze als in de SNO is uitgewerkt. Implementatiepartner is verplicht daartoe een servicedesk in stand te houden. 8.3 Gemeente is gerechtigd na voorafgaande schriftelijke kennisgeving elke Verbeterde of Nieuwe Versie door een (onafhankelijke) derde deskundige opnieuw te laten onderzoeken ter verkrijging van een Third Party Mededeling conform het Voorschrift Informatiebeveliging Rijksdienst (VIR), alvorens deze Versie te accepteren. 8.4 Het is Implementatiepartner niet toegestaan voor de levering van Onderhoud te verwijzen naar zijn algemene support policies. Voor de levering van Onderhoud gelden uitsluitend de bepalingen van deze Overeenkomst en het SNO. 8.5 De levering van Onderhoud kan tussentijds partieel of geheel schriftelijk worden opgezegd door Gemeente met inachtneming van een opzegtermijn van drie maanden. De opzegging kan uitsluitend geschieden in het geval de Gemeente niet langer gebruik maakt van de aangegeven hoeveelheid Licenties waarvoor de opzegging geldt. Partiële opzegging is alleen mogelijk indien de Midoffice Suite uit een package bestaat en als er sprake is van een Voortdurende Licentie. Artikel 9: <Licentie><Voortdurende Licentie> 9.1 Voor zover uit deze Overeenkomst niet uitdrukkelijk het tegendeel blijkt, omvat de sub 2.2 bedoelde <Licentie><Voortdurende Licentie> de toestemming tot het verrichten of doen verrichten van alle auteursrechtelijke bevoegdheden die uit de Auteurswet 1912 voortvloeien met betrekking tot of samenhangend met het gebruik van de Midoffice Suite door of ten behoeve van Gemeente, ongeacht op welke wijze en in welke vorm, dit alles ten behoeve van het optimaal gebruik van de Midoffice Suite, waartoe deze beoogd is en/of geschikt is of blijkt of kan zijn, mits in het kader van de normale activiteiten van Gemeente. 9.2 De <Licentie><Voortdurende Licentie> is in Bijlage D beschreven. Implementatiepartner is, indien hij gebruiksrechten categoriseert naar soort gebruik(ers), te allen tijde verplicht deze gebruiksrechten in het kader van de <Licentie><Voortdurende Licentie> op de voor Gemeente vanuit financieel oogpunt zo gunstig mogelijk wijze te categoriseren, waarbij een redelijk gebruik steeds mogelijk blijft. 9.3 Implementatiepartner verplicht zich, onverkort het sub artikel 7.2 gestelde, Gemeente zo spoedig mogelijk, doch uiterlijk met een minimale termijn van 12 maanden voorafgaand aan beëindiging, schriftelijk te informeren over het voornemen tot beëindigen van de productie van en/of de mogelijkheid tot het verrichten van Onderhoud op de Midoffice Suite conform de service levels zoals in de SNO is bepaald. 9.4 Implementatiepartner verplicht zich de mogelijkheid Verbeterde Versies of Nieuwe Versies uit te brengen bij voortduring en in voldoende mate te onderzoeken en Gemeente melding te doen van informatiebeveilgingsincidenten die zich ten aanzien van de Midofficesuite bij een andere in het Bestek genoemd consortium deelnemende gemeente voordoen. Implementatiepartner heeft steeds de plicht om Nieuwe Versies onder de voorwaarden en afspraken van de Overeenkomst en SNO aan Gemeente in <Licentie><Voortdurende Licentie> beschikbaar te stellen. Implementatiepartner informeert Gemeente zes maanden voor het uitbrengen van een Verbeterde Versie of Nieuwe Versie over de inhoud en gevolgen m.b.t. het Systeem. Bij het aanbieden van Nieuwe Versies zal Implementatiepartner zo mogelijk rekening houden met de functionele wensen van Gemeente. 159 Paraaf Gemeente: Paraaf Implementatiepartner:

160 Gemeente concept v1.0 Gemeente heeft het recht, maar niet de plicht om de Midoffice Suite telkens naar een Nieuwe Versie te (doen) migreren. Implementatiepartner blijft verplicht het afgesproken Onderhoud te verzorgen, ook indien de door de Gemeente gekozen Versie tot en met twee Versies achterblijft bij de laatst uitgebrachte Nieuwe Versie. 9.5 Tijdens de duur van deze Overeenkomst is Gemeente steeds gerechtigd, maar niet verplicht, onder gelijke condities additionele <Licenties><Voortdurende Licenties> bij Implementatiepartner aan te schaffen. Implementatiepartner is verplicht om additionele <Licenties><Voortdurende Licenties> overeenkomstig dit artikellid te leveren, ook als Gemeente besluit om een oudere versie van de Midoffice Suite te blijven gebruiken. 9.6 Indien Materialen tijdens deze Overeenkomst door beschadiging, brand, verlies of diefstal geheel of gedeeltelijk verloren gaan, is Implementatiepartner verplicht tegen kostprijs nieuwe Materialen te leveren. 9.7 Periodieke meting door of vanwege Implementatiepartner van de hoeveelheid bij Gemeente in gebruik zijnde <Licenties><Voortdurende Licenties> kan eerst plaatsvinden nadat Partijen overeenstemming hebben over de wijze van meting, onverkort de verplichting van Gemeente om voor betaling van de juiste hoeveelheid in gebruik zijnde <Licenties><Voortdurende Licenties> zorg te dragen. Artikel 10: Aansprakelijkheid 10.1 De aansprakelijkheid van Implementatiepartner in het kader van een handelen of nalaten wordt als volgt beperkt: voor zaakschade, dat wil zeggen beschadiging, vernietiging, gebrekkig of niet functioneren, verminderde betrouwbaarheid en verhoogde storingsgevoeligheid en verlies van apparatuur, alsmede vuil worden van zaken van Gemeente en/of derden, met inbegrip van de daaruit voortvloeiende op geld waardeerbare gevolgschade, tot een bedrag van ,00 per gebeurtenis en gemaximeerd tot tweemaal per kalenderjaar; voor financieel nadeel, dat wil zeggen door Gemeente geleden directe schade in het vermogen (financieel nadeel) dat voortvloeit uit handelen of nalaten in verband met de uitvoering van diensten en/of werkzaamheden tot een bedrag van ,00 per gebeurtenis en gemaximeerd tot tweemaal per kalenderjaar De aansprakelijkheid voor personenschade, dat wil zeggen letsel of aantasting van de gezondheid van personen, al dan niet de dood ten gevolge hebbend, met inbegrip van de daaruit voortvloeiende op geld waardeerbare gevolgschade, is onbeperkt De sub 10.1 opgenomen beperking van aansprakelijkheid komt te vervallen indien er sprake is van opzet en/of grove schuld en/of schending van intellectuele en industriële eigendomsrechten, waaronder begrepen inbreuk op of onbevoegd gebruik van systemen of programma s van derden Gebeurtenissen die met elkaar verband houden, of uit elkaar of uit hetzelfde handelen of nalaten voortvloeien, zullen als één gebeurtenis worden beschouwd en worden geacht te zijn gevorderd op het moment dat de eerste gebeurtenis heeft plaatsgevonden Iedere schade die wordt geleden door een door Gemeente in het kader van de uitvoering van deze Overeenkomst ingeschakelde derde, wordt geacht schade van Gemeente te zijn. 160 Paraaf Gemeente: Paraaf Implementatiepartner:

161 Gemeente concept v1.0 Artikel 11: Prijzen 11.1 De maximum prijs van alle door Implementatiepartner te verrichten werkzaamheden ter oplevering van het Resultaat is vastgelegd in Bijlage D. De prijs heeft betrekking op alle door Implementatiepartner in het kader van deze Overeenkomst te verrichten prestaties, met uitzondering van de kosten die zijn verbonden aan de <Licenties><Voortdurende Licenties> en de levering van Onderhoud. Onderdeel van de maximum prijs zijn ook de beschikbaarstelling van computers en materialen, de kosten van verzekering, reis- en verblijfskosten van Personeel van Implementatiepartner Indien door onvoorziene additionele wensen van Gemeente de prestaties welke Implementatiepartner op grond van deze Overeenkomst moet leveren aantoonbaar worden verzwaard, c.q. uitgebreid, is er sprake van meerwerk welke voor vergoeding in aanmerking komt. Indien Implementatiepartner meent dat van meerwerk sprake zal zijn, zal hij daarvan zo spoedig mogelijk, doch in ieder geval uiterlijk zeven kalenderdagen voor aanvang van de werkzaamheden, schriftelijk melding maken aan Gemeente Tot meerwerk worden niet gerekend additionele werkzaamheden, die Implementatiepartner redelijkerwijs bij het sluiten van deze Overeenkomst had kunnen of moeten voorzien Als vergoeding voor het verlenen van de <Licentie><Voortdurende Licentie>, zoals in sub 2.1 aangegeven, betaalt Gemeente de bedragen als vastgelegd in Bijlage D. Indien de vergoeding voor de levering van Onderhoud een jaarlijks percentage bedraagt dan is dit een percentage van de netto eenmalige aanschafprijs van de Midoffice Suite. Dit percentage is vast en onveranderlijk gedurende de gehele looptijd van de Overeenkomst en geldt tevens voor de aanschaf van Onderhoud op additionele <Licenties><Voortdurende Licenties>. Indien de vergoeding voor het verlenen van de Licentie uit een jaarlijks te betalen bedrag bestaat dan is de vergoeding voor de betaling van het Onderhoud hierbij inbegrepen. Het jaarlijks te betalen bedrag voor het verlenen van de Licentie, het Onderhoud daarbij begrepen, of het jaarlijks te betalen bedrag voor de levering van Onderhoud, indien dit bedrag is gebaseerd op het hiervoor genoemde vaste percentage, kan tot niet worden verhoogd bij een gelijkblijvend aantal Licenties. Vanaf kan het jaarlijks te betalen bedrag voor Licenties, het Onderhoud daarbij begrepen c.q het Onderhoud met een maximum percentage van 3% worden verhoogd. Voor op enig moment additioneel aangekochte Licenties wordt per Licentie een bedrag aan Onderhoud betaald gelijk aan het bedrag dat op dat moment door Gemeente wordt betaald voor Onderhoud op reeds aangekochte <Licenties><Voortdurende Licenties>, gerekend per <Licentie><Voortdurende Licentie>. De prijs van het Onderhoud kan echter niet verder worden verhoogd dan met het percentage dat Implementatiepartner standaard hanteert voor iedere klant Indien de vergoeding voor het verlenen van de Licentie uit een jaarlijks te betalen bedrag bestaat dan wordt éénmaal per jaar de juiste hoeveelheid in gebruik zijnde Licenties bepaalt door Partijen, rekening houdend met het gestelde sub 9.7. Indien bij meeting wordt vastgesteld dat de hoeveelheid in gebruik zijnde Licenties minder bedraagt dan de hoeveelheid waarvoor Gemeente betaalt, dan heeft Gemeente het recht de hoeveelheid niet in gebruik zijnde Licenties met een opzegtermijn van drie maanden schriftelijk op te zeggen Implementatiepartner is gedurende twee jaar na afloop van de maximale looptijd van deze Overeenkomst verplicht artikel 11.4 overeenkomstig toe te passen indien Partijen besluiten een nieuwe overeenkomst af te sluiten ter zake van de levering van <Licenties><Voortdurende Licenties> en/of Onderhoud Alle prijzen en tarieven zijn steeds vastgesteld in Euro s inclusief het geldende percentage omzetbelasting De navolgende diensten zullen door Implementatiepartner tot de laatste Acceptatie steeds kosteloos worden verleend: periodieke rapportages, periodiek overleg, inspecties, evaluaties, toekomstverkenningen, deelname aan begeleidings- en stuurgroepen. 161 Paraaf Gemeente: Paraaf Implementatiepartner:

162 Gemeente concept v1.0 Artikel 12: Betaling 12.1 Betaalschema: softwarelicenties mogen worden gefactureerd na Acceptatie van de inrichting van de top-7 producten door Gemeente. Van het resterende bedrag mag 40% na installatie, 20% na basisconfiguratie, 20% na Oplevering van de in het Programma van Eisen beschreven top-7 producten en 20% na Acceptatie van de top-7 producten wordt gefactureerd. Onderhoud wordt per jaar achteraf betaald en kan, rekening houdend hiermee, na afloop van de garantietermijn in rekening worden gebracht. Additionele softwarelicenties die ná Acceptatie van de top-7 producten worden geleverd worden direct na aflevering gefactureerd Gemeente betaalt de sub 11.1 en 12.1 verschuldigde bedragen binnen 30 dagen na ontvangst van de betreffende factuur op de daartoe door Implementatiepartner aangegeven bank-/girorekening Meerwerk wordt door Implementatiepartner na voltooiing van de meerwerkzaamheden apart gefactureerd. De aard en omvang van de verrichte meerwerkzaamheden worden uitdrukkelijk in de facturen vermeld en - aan de hand van authentieke bescheiden - gespecificeerd Met betrekking tot het verrichten van werkzaamheden in het kader van de oplevering van het Resultaat betaalt Gemeente na Acceptatie van het overeengekomen Resultaat. Indien er door Gemeente betalingen worden gedaan in het kader van dienstverlening of het verstrekken van een <Licentie><Voortdurende Licentie> vóórdat Acceptatie heeft plaatsgevonden dan geschiedt deze betaling steeds onder het voorbehoud van Acceptatie Implementatiepartner zendt facturen in enkelvoud aan Gemeente toe onder vermelding van de schriftelijk aan hem kenbaar gemaakte gegevens De factuur wordt door Implementatiepartner voorzien van datum, contractnummer, en andere door Gemeente schriftelijk aan hem kenbaar gemaakte gegevens Gemeente is te allen tijde gerechtigd door Implementatiepartner verzonden facturen door een door Gemeente aan te wijzen Register-Accountant op inhoudelijke juistheid te doen controleren. Implementatiepartner verleent de betrokken Register-Accountant inzage van boeken en bescheiden en verstrekt alle gegevens en informatie, welke deze verlangt. De controle is vertrouwelijk en strekt zich niet verder uit dan voor het verifiëren van de facturen is vereist. De Register-Accountant zal zijn rapportage zo spoedig mogelijk aan beide Partijen uitbrengen. Gemeente is gerechtigd betaling op te schorten gedurende de periode van het accountantsonderzoek. Van deze bevoegdheid zal Gemeente uitsluitend gebruik maken indien bij Gemeente gerede twijfel bestaat omtrent de juistheid van de betreffende facturen en uitsluitend voor het betwiste deel van de factuur. De kosten van het accountants-onderzoek komen voor rekening van Gemeente, tenzij uit het onderzoek blijkt dat de factuur niet geheel juist was Overschrijding van (een) betalingstermijn(en) door Gemeente of niet-betaling door Gemeente van (een) fact(u)ur(en) op grond van vermoede inhoudelijke onjuistheid van die fact(u)ur(en) of van ondeugdelijkheid van de gefactureerde prestaties geeft Implementatiepartner niet het recht zijn prestaties op te schorten c.q. te beëindigen. Artikel 13: Intellectuele (eigendoms)rechten 13.1 Alle intellectuele eigendomsrechten, die - waar en wanneer dan ook - ten aanzien van het Resultaat, maatwerk(aanpassingen) daaronder begrepen, en Documentatie kunnen of zullen kunnen worden uitgeoefend, berusten bij Implementatiepartner Onverminderd de in deze Overeenkomst aan Gemeente toegekende bevoegdheden, berusten de intellectuele (eigendoms)rechten, welke ten aanzien van de Midoffice Suite kunnen worden uitgeoefend bij Implementatiepartner of diens toeleverende derde (rechthebbende). 162 Paraaf Gemeente: Paraaf Implementatiepartner:

163 Gemeente concept v Implementatiepartner vrijwaart Gemeente voor aanspraken van derden terzake van (eventuele) inbreuk op intellectuele (eigendoms)rechten van die derden, vergelijkbare aanspraken met betrekking tot knowhow, ongeoorloofde mededinging e.d. daaronder begrepen. Deze vrijwaring geldt niet indien bedoelde aanspraken van derden betrekking hebben op diensten welke niet door Implementatiepartner in het kader van deze, of enige andere overeenkomst tussen Partijen, aan Gemeente zijn geleverd of ter beschikking gesteld. Implementatiepartner verplicht zich tot het, op zijn kosten, treffen van alle maatregelen die kunnen bijdragen tot voorkoming van stagnatie bij Gemeente en tot beperking van de door Gemeente te maken extra kosten en/of te lijden schade. Onverminderd het hiervoor in dit lid bepaalde, is Gemeente gerechtigd, indien derden Gemeente terzake van schending van intellectuele (eigendoms)rechten aansprakelijk stellen, deze Overeenkomst schriftelijk, buiten rechte, geheel of gedeeltelijk, al dan niet met terugwerkende kracht, te beëindigen, onverminderd haar verdere rechten De intellectuele (eigendoms)rechten van met de Midoffice Suite tot stand gebrachte softwarebestanden, danwel (ordening van) informatie komen toe aan Gemeente. Hierbij kan onder meer worden gedacht aan de inrichting van het gegevens- en zakenmagazijn. Ook in geval van maatwerk in opdracht van Gemeente komen de intellectuele (eigendoms)rechten toe aan Gemeente. Artikel 14: Geheimhouding en beveiliging 14.1 Onverminderd de in deze Overeenkomst aan Gemeente toegekende rechten, zullen beide Partijen strikte vertrouwelijkheid in acht nemen t.a.v. de informatie over elkaars organisatie, de werking van de Systemen, de bestanden en programmatuur. Behoudens voorafgaande schriftelijke toestemming van de andere Partij zal ieder der Partijen informatie en gegevensdragers welke hem ter beschikking staan, niet buiten het kader van hetgeen in deze Overeenkomst is toegestaan aan derden ter beschikking stellen en aan zijn personeel en voor zover dit krachtens deze Overeenkomst is toegestaan aan desbetreffende derden slechts bekend maken voor zover dit nodig is voor het verrichten van de overeengekomen prestaties. Partijen zullen hun Personeel en eventueel door hen ingeschakelde derden verplichten deze geheimhoudingsbepalingen na te leven. Indien door één der Partijen wordt gehandeld in strijd met deze bepaling verbeurt die Partij, zonder dat enige aanmaning of ingebrekestelling is vereist, in elk van deze gevallen een dadelijk opeisbare, niet voor compensatie vatbare boete aan de andere Partij van 5.000,00 per gebeurtenis. Deze boete laat de overige rechten van de andere Partij, waaronder die op schadevergoeding, onverlet Personeel van Implementatiepartner dat betrokken is bij de uitvoering van de werkzaamheden, voorzover die bij Gemeente worden verricht, is verplicht door Gemeente aangehouden beveiligingsprocedures in acht te nemen. Gemeente is gerechtigd te vorderen dat van personeel dat door Implementatiepartner bij de uitvoering van de Overeenkomst wordt ingezet vooraf verklaringen omtrent het gedrag worden overgelegd. Gemeente is te allen tijde gerechtigd personeel van Implementatiepartner, dat voor de uitvoering van de Overeenkomst is of wordt ingeschakeld, aan een veiligheidsonderzoek conform de bij Gemeente gebruikelijke regels te onderwerpen. Implementatiepartner verleent aan dit onderzoek zijn volledige medewerking. Gemeente is gerechtigd op grond van de uitkomsten van een dergelijk veiligheidsonderzoek, zonder opgave van redenen te weigeren dat het betrokken personeelslid bij de uitvoering van de Overeenkomst wordt ingezet. Implementatiepartner is in dat geval verplicht dat personeelslid door een andere, qua opleiding, ervaring en deskundigheid gelijkwaardig personeelslid te vervangen en ten aanzien van het vervangen personeelslid de geheimhouding sub 14.1 bedoeld in acht te nemen Implementatiepartner maakt zonder schriftelijke toestemming van Gemeente in publicaties of reclame-uitingen geen melding van deze Overeenkomst Gemeente is gerechtigd tot inzage in de informatiebeveiligingsvoorzieningen die Implementatiepartner voert bij de uitvoering van de Overeenkomst en mag hieraan passende eisen stellen, waaraan Implementatiepartner onverwijld dient te voldoen. 163 Paraaf Gemeente: Paraaf Implementatiepartner:

164 Gemeente concept v1.0 Artikel 15: Verzekering 15.1 Implementatiepartner heeft zich op een naar verkeersnormen passende en gebruikelijke wijze verzekerd en verleent Gemeente desgewenst inzage in de betreffende polissen. De verzekerde bedragen dekken in ieder geval de aansprakelijkheid zoals in artikel 10 bedoeld. De door Implementatiepartner verschuldigde verzekeringspremies worden geacht in de overeengekomen prijzen en tarieven te zijn begrepen. Artikel 16: Ondersteuning 16.1 Implementatiepartner maakt (personeel van) Gemeente op diens verzoek vertrouwd met het gebruik van en de onderhoudsverlening ten aanzien van de Midoffice Suite. De ondersteuning wordt gegeven door deskundigen, die daartoe bekwaam en geschikt zijn en zoveel mogelijk gegeven door díe deskundigen die bij de installatie zijn of waren betrokken. De aard, omvang, duur en kosten van de ondersteuning alsmede de aard van deskundigen worden in het Projectplan vermeld. Artikel 17: Documentatie 17.1 Documentatie, die in het kader van het Resultaat door Implementatiepartner dient te worden opgeleverd, dient in het Nederlands en binnen dezelfde termijn als de termijn die geldt voor het Opleveren van het overeengekomen deel van de Prestatie in artikel 6.1 bedoeld te worden opgeleverd aan Gemeente ter Acceptatie De Documentatie dient zodanig te zijn dat: zij een juiste, volledige en gedetailleerde beschrijving geeft van het door Implementatiepartner te op te leveren Midoffice Suite en de functies daarvan; installatie door personeel van Gemeente op eenvoudige wijze mogelijk is; gebruikers op eenvoudige wijze van alle mogelijkheden van de Midoffice Suite gebruik kunnen maken; onderhoud van de Midoffice Suite ook door derden kan plaatsvinden; ze voldoet aan de in het Programma van Eisen vermelde vereisten; ze het Gemeente mogelijk maakt de Midoffice te doen communiceren met andere onderdelen van de Systemen en van de systemen van ketenpartners Gemeente is gerechtigd de Documentatie voor gebruik in de eigen organisatie gratis te reproduceren en te wijzigen, mits met instandhouding van aanduidingen van auteursrecht e.d., die op originele exemplaren zijn vermeld of met toevoegingen van die aanduidingen als door de Implementatiepartner verlangd Implementatiepartner draagt er zorg voor dat de door hem geleverde Documentatie zo spoedig mogelijk op zijn kosten wordt vervangen, gewijzigd of aangepast indien op enig tijdstip tijdens het gebruik door Gemeente van de Midoffice Suite mocht blijken dat de Documentatie onjuiste informatie bevat of anderszins onvolledig, onvoldoende, onduidelijk of verouderd is De kosten van documentatie zijn in de prijs van de <Licentie><Voortdurende Licentie> opgenomen. 164 Paraaf Gemeente: Paraaf Implementatiepartner:

165 Gemeente concept v1.0 Artikel 18: Niet toerekenbare tekortkoming (overmacht) 18.1 In geval van overmacht wordt de nakoming door de betrokken Partij van de uit deze Overeenkomst voortvloeiende verplichtingen geheel of gedeeltelijk opgeschort voor de duur van zodanige overmacht, zonder dat de Partijen over en weer tot enige schadevergoeding ter zake gehouden worden. Partijen kunnen zich slechts op overmacht beroepen, wanneer daarvan zo spoedig mogelijk onder overlegging van de benodigde bewijsstukken schriftelijk aan de andere Partij mededeling wordt gedaan Onder overmacht wordt niet gerekend: gebrek aan personeel, stakingen, ziekte van personeel, verlate aanlevering of ongeschiktheid van Materialen, een toerekenbare tekortkoming van zijdens een Partij ingeschakelde derde en/of liquiditeits- c.q solvabiliteitsproblemen. Artikel 19: Ontbinding 19.1 Buiten hetgeen elders in deze Overeenkomst is bepaald is: ieder der Partijen gerechtigd deze Overeenkomst d.m.v. een aangetekend schrijven buiten rechte te ontbinden indien de andere Partij ook na schriftelijke aanmaning stellende een redelijke termijn in gebreke blijft aan zijn verplichtingen uit deze Overeenkomst te voldoen, of indien de in artikel 19 lid 1 voor de wederpartij benoemde situatie van overmacht meer dan zestig dagen heeft geduurd, of indien voorzien kan worden dat zij meer dan zestig dagen zal duren Gemeente gerechtigd zonder dat enige aanmaning of ingebrekestelling zal zijn vereist en buiten rechte, deze Overeenkomst d.m.v. een aangetekend schrijven met onmiddellijke ingang te ontbinden indien Implementatiepartner surséance c.q. voorlopige surséance van betaling aanvraagt of hem surséance c.q. voorlopige surséance van betaling wordt verleend; Implementatiepartner zijn faillissement aanvraagt of in staat van faillissement wordt verklaard; de onderneming van Implementatiepartner wordt geliquideerd; Implementatiepartner zijn huidige onderneming staakt; op een aanmerkelijk deel van het vermogen van Implementatiepartner dan wel op de Midoffice Suite beslag wordt gelegd dan wel Implementatiepartner anderszins niet langer in staat moet worden geacht de verplichtingen uit deze Overeenkomst na te kunnen komen Deze Overeenkomst kan door Gemeente, zonder enige gehoudenheid tot vergoeding van de daaruit mogelijkerwijs voor Implementatiepartner voortvloeiende schade, worden ontbonden, indien de uit deze Overeenkomst voortvloeiende verbintenis door enige gerechtelijke uitspraak als onrechtmatig wordt geoordeeld. In dat geval zal Gemeente aan Implementatiepartner uiterlijk binnen 21 dagen na de datum van een dergelijke uitspraak mededelen, of hij op grond daarvan overgaat tot ontbinding van de Overeenkomst. Artikel 20: Overdracht rechten en verplichtingen; onderaanneming 20.1 Partijen zijn niet gerechtigd de rechten en verplichtingen uit deze Overeenkomst zonder schriftelijke toestemming van de andere Partij aan een derde over te dragen. Deze toestemming wordt niet zonder redelijke grond geweigerd; de toestemming verlenende Partij is echter gerechtigd aan het verlenen van deze toestemming voorwaarden te verbinden. Dochterbedrijven van Partijen worden als derde beschouwd. 165 Paraaf Gemeente: Paraaf Implementatiepartner:

166 Gemeente concept v Indien er van de zijde van Gemeente (a) sprake is van uitbesteding van het beheer van de gegevensverwerking, of (b) sprake is van verzelfstandiging van een deelorganisatie die de werkzaamheden m.b.t. het in deze Overeenkomst bedoelde Midoffice Suite (deels) gaat verrichten, is Gemeente gerechtigd de door haar krachtens deze Overeenkomst verkregen <Licentie><Voortdurende Licentie> tegelijk daarmee over te dragen aan deze derde, mits deze derde solvabel is en bereid is de daarmee corresponderende verplichtingen jegens de Implementatiepartner over te nemen. Gemeente is daarmee van haar verplichtingen jegens Implementatiepartner gekweten. Implementatiepartner stelt noch aan Gemeente, noch aan de derde aanvullende voorwaarden. Artikel 21: Geschillen en toepasselijk recht 21.1 Ieder geschil tussen Partijen terzake van deze Overeenkomst wordt bij uitsluiting voorgelegd aan de daartoe bevoegde rechter in het arrondissement waar Gemeente is gevestigd tenzij Partijen alsnog arbitrage of bindend advies overeenkomen In geval van een geschil sub 21.1 bedoeld, geeft de meest gerede van Partijen aan de andere Partij schriftelijk te kennen, dat er sprake is van een geschil, alsmede een summiere, doch alle elementen en grieven omvattende opgave van hetgeen naar het oordeel van die Partij het onderwerp van het geschil is Op deze Overeenkomst is Nederlands recht van toepassing. Artikel 22: Algemeen 22.1 De algemene leverings- en betalingsvoorwaarden van Implementatiepartner, dan wel andere algemene of bijzondere voorwaarden zijn niet van toepassing Kennisgevingen die Partijen op grond van deze Overeenkomst aan elkaar zullen doen, vinden schriftelijk plaats. Mondelinge mededelingen, toezeggingen of afspraken hebben geen rechtskracht tenzij deze schriftelijk zijn bevestigd Geen van Partijen is bevoegd personeelsleden van de andere Partij te bewegen tot prestaties, toezeggingen en dergelijke, tegen enige vorm van beloning of gift aan dat personeelslid, zonder welke beloning of gift de prestatie of toezegging niet, c.q. onder andere voorwaarden, tot stand zou zijn gekomen. Indien het personeel van een van Partijen in strijd met het hier bepaalde handelt, verbeurt deze Partij zonder dat enige sommatie of ingebrekestelling is vereist in elk van deze gevallen een dadelijk opeisbare, niet voor compensatie vatbare boete aan de andere Partij van ,00 per overtreding. Deze boete laat de overige rechten van de andere Partij, waaronder die op schadevergoeding en/of volledige nakoming onverlet. Aldus overeengekomen en in tweevoud ondertekend, d.d. <datum> Namens Gemeente Namens Implementatiepartner 166 Paraaf Gemeente: Paraaf Implementatiepartner:

167 8.13 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. Europese aanbesteding , 28 maart

168 3.5 Na beëindiging van de overeenkomst zal Opdrachtgever de Producten aan Leverancier terug geven, tenzij partijen anders overeenkomen. 3.6 Per Inschrijver wordt een vergoeding van 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. 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. Europese aanbesteding , 28 maart

169 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. 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. Europese aanbesteding , 28 maart

170 8.14 Voorbeeld Service Niveau Overeenkomst Inleiding Naast het installeren en implementeren van de aangeboden Midoffice Suite dient de Inschrijver zorg te dragen voor het onderhoud ervan. Het onderhoud omvat het verrichten van alle activiteiten die nodig zijn voor het waarborgen van de functionaliteit en ononderbroken goede werking van de Midoffice Suite. De Midoffice Suite omvat alle aangeboden software inclusief add-ons en maatwerk zoals aangegeven in de controlelijst vragen en functionaliteit (Bijlage 8.10). Het onderhoud zal plaatsvinden op basis van een Service Niveau Overeenkomst (SNO). Deze paragraaf bevat een beschrijving van het onderhoud, op basis waarvan Inschrijver de SNO nader kan uitwerken, waarna deze door de gemeente dient te worden goedgekeurd. De twee belangrijkste taken van het onderhoud zijn de levering van nieuwe versies en het herstel van gebreken. Levering van nieuwe versies Als er een nieuwe versie van software beschikbaar is voor de aangeboden Midoffice Suite dient de Inschrijver deze versie binnen 10 werkdagen beschikbaar te stellen aan de gemeente. Een nieuwe versie is een gewijzigde c.q. opvolgende versie van de Midoffice Suite, waardoor (al of niet op verzoek vande gemeente) de functionaliteit daarvan wordt vergroot of de logische samenhang wordt verbeterd. 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. Herstel van gebreken en beantwoorden van functionele en/of technische vragen Een gebrek is het niet c.q. niet volledig voldoen van de Midoffice Suite aan de overeengekomen functionele specificaties, zoals verwoord in het Programma van Eisen (hoofdstuk 5), dan wel het vanuit technische optiek niet naar behoren functioneren van de Midoffice Suite. Inschrijver dient gebreken te herstellen. Om beide taken naar behoren te kunnen uitvoeren is Inschrijver verplicht een servicedesk in stand te houden. De volgende paragraaf beschrijft globaal de positionering en taken van de servicedesk. Servicedesk Gebruikers, beheerders en medewerkers van de gemeente kunnen in eerste instantie voor zowel functionele als technische vragen terecht bij de helpdesk van de gemeente. Deze fungeert voor de gemeentelijke organisatie als eerste lijns helpdesk. Indien de vragen niet door de gemeentelijke helpdesk kunnen worden opgelost, hebben alleen de helpdesk medewerkers toegang tot de servicedesk van de Inschrijver, die voorziet in tweedelijns support bij incidenten, gebreken, vragen en klachten, om zo snel mogelijk de dienstverlening te herstellen en de gemeente optimaal te ondersteunen in het gebruik van haar dienstverlening. De servicedesk heeft de volgende taken: o Registratie: alle ontvangen calls, waaronder incidenten en gebreken vastleggen in een registratiesysteem en het doorgeven van een registratienummer aan de melder. Europese aanbesteding , 28 maart

171 o De servicedesk volgt en bewaakt het oplossen van verstoringen in de dienstverlening, de afhandeling van de wijziging, de beantwoording van vragen en de terugmelding en rapportage van de melding. De servicedesk houdt de aanvrager op de hoogte van de status. o Classificatie: incidenten worden door de helpdesk geclassificeerd volgens de prioriteitentabel in Tabel 8-4. o Callrapport: voor alle incidenten wordt een callrapport gemaakt. Een callrapport bevat o.a. eindgebruikergegevens, callnummer, prioriteit, begindatum en tijdstip, aard van de meldingen verloop van de afhandeling, datum en tijd afmelding. o Bij afmelding van de call ontvangt de gemeente een bericht. Afsluiting van een incident vindt plaats na goedkeuring door de melder. De ondersteuning door de servicedesk moet in de Nederlandse taal beschikbaar zijn. De reactie- en afhandelingsnelheid van calls, waaronder incidenten en gebreken gebeurt op basis van een prioriteitsclassificatie en de reactie- en afhandeltijden staan in onderstaande Tabel 8-3. Prioriteit Reactietijd Eerste probleemstatus melding Acceptabele oplossing of workaround beschikbaar Definitieve oplossing beschikbaar Hoog ½ uur Binnen 1 uur 4 uren 1 week Midden 1 uur Binnen 2 uren 2 werkdagen 2 weken Laag 2 uren Binnen 1 werkdag 5 werkdagen 4 weken Tabel 8-3 Reactie- en afhandeltijden De impact van een incident of gebrek op de dienst wordt aangegeven in de vorm van een prioriteitsclassificatie. Er worden drie prioriteitsclassificaties onderscheiden: hoog, midden en laag. De prioriteitsclassificaties zijn weergegeven in Tabel 8-4. Prioriteiten Severity Omschrijving Hoog 1 Ernstig incident/gebrek Incident betreft functionaliteit t.b.v. burgers. Midden 2 Middel incident/gebrek Incident betreft functionaliteit t.b.v. medewerkers. Laag 3 Gering incident/gebrek Incident betreft functionaliteit t.b.v. beheerders. Tabel 8-4 Prioriteitentabel Minimaal 90% van de incidenten/gebreken wordt volgens bovenstaande normen afgehandeld. Voor de incidenten / gebreken waarin deze normen overschreden (dreigen te) worden stelt Inschrijver de gemeente op de hoogte waarbij zowel de reden van de overschrijding als de verwachte oplostermijn wordt aangegeven. De servicedesk is op werkdagen van 8:00 uur tot 18:00 uur telefonisch, via en via fax bereikbaar voor het aannemen van incidenten, gebreken, het beantwoorden van vragen en wijzigingsverzoeken. De bereikbaarheid voor telefonische meldingen bij de servicedesk bedraagt 99,9%. Hierbij worden niet meegerekend: storingen aan de zijde van de gebruiker, Europese aanbesteding , 28 maart

172 storingen in het openbare telefoonnet en storingen als gevolg van overmachtsituaties. Het maximale aantal keren dat de helpdesk onbeschikbaar is bedraagt viermaal per kalenderjaar. Deze beschrijving gaat ervan uit dat change management geen onderdeel is van het onderhoud. Europese aanbesteding , 28 maart

173 8.15 Conformiteitenlijst conceptovereenkomst Deze conformiteitenlijst biedt de mogelijkheid om per artikel van de conceptovereenkomst (zie bijlage 8.12) 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 front- en midoffice Artikelnummer Wel Akkoord Niet Akkoord Tekstvoorstel Considerans 1 Begrippen Onderwerp Europese aanbesteding , 28 maart

174 Vertegenwoordiging, projectleiding, (voortgangs)rapportage en overleg Aanvang werkzaamheden; duur van de Overeenkomst Wijzigen van de Overeenkomst Oplevering en Acceptatie Garantie Onderhoud <Licentie><Voortdurende Licentie> Europese aanbesteding , 28 maart

175 Aansprakelijkheid Prijzen Betaling Intellectuele (eigendoms)rechten Geheimhouding en beveiliging Verzekering Ondersteuning Documentatie Europese aanbesteding , 28 maart

176 Niet toerekenbare tekortkoming (overmacht) Ontbinding Overdracht rechten en verplichtingen; onderaanneming Geschillen en toepasselijk recht Algemeen Europese aanbesteding , 28 maart

177 8.16 Voorbeeld procesafhandeling Aanvraag evenementenvergunning Onderstaand volgt de beschrijving van de implementatie van het zaaktype aanvraag vergunning klein evenement, zoals door de gemeente Dordrecht gebruikt in Mozaiek. Deze beschrijving dient als voorbeeld tbv. de PoC. De Gemeenten begrijpen dat een gelijke inrichting niet mogelijk zal zijn, maar de Top-n wordt gevraagd op basis van deze beschrijving de Aanvraag evenementenvergunning in te richten. Paragraaf geeft voorbeeldformulieren van de gemeente Veghel. Hoewel in deze beschrijving dienstverlening aan burgers en bedrijven wordt beschreven, kan ten behoeve van de PoC worden gefocust op burgers (en dus kan de problematiek rondom bedrijven worden genegeerd). Deze bijlage schetst hoe in Mozaiek een zaaktype wordt geconfigureerd (1), hoe zaken worden behandeld (2) en hoe met klanten wordt gecommuniceerd m.b.t. deze zaken (3). Ter verduidelijking zijn de daadwerkelijke gegevens van het zaaktype aanvraag vergunning klein evenement steeds cursief opgenomen Configuratie zaaktype Per zaaktype wordt vastgelegd: - algemene kenmerken van het zaaktype - de autorisaties - de statussen - de ontvangstbevestiging - de relevante besluiten - de mogelijke resultaten - de relevante documenten - de relevante kenmerken per zaak - de relevante koppelingen registraties in het gegevensmagazijn - verplichte documenten per status/resultaat - verplichte kenmerken per status/resultaat - verplichte koppelingen per status/resultaat - checklist per status/resultaat Europese aanbesteding , 28 maart

178 Algemene kenmerken van het zaaktype Naast de naam van het zaaktype => aanvraag vergunning klein evenement, leggen we t.b.v. publicaties van vergunningen op AdviesOverheid ook de naam ao vast => evenementenvergunning. Als verantwoordelijke leggen we het organisatieonderdeel vast => PD/BOWO/VG, welke eindverantwoordelijk is (ook als er meerdere afdelingen betrokken zijn bij de afhandeling, kiezen we één organisatieonderdeel als eindverantwoordelijke). We noteren zowel doorlooptijd gewenst => 21 dagen, als doorlooptijd vereist => 56 dagen. De eerste waarde geeft de servicenorm weer. De tweede waarde de wettelijk toegestane doorlooptijd. Mozaiek baseert zich bij het afhandelen op de eerste waarde, maar kan bij de managementinformatie ook rekening houden met de tweede waarde. Met doorlooptijd oranje => 3 dagen en doorlooptijd rood => 1 dag, kan worden aangegeven wanneer de resterende doorlooptijd van zaken in de taakbak in oranje of rood moet worden weergegeven. Er kan worden aangegeven of en met welke termijn zaken van dit type kunnen worden verlengd => ja, 28 dagen. Door het invoeren van een publicatietekst worden zaken automatisch gepubliceerd op zowel de website als bij AdviesOverheid. Op termijn zullen ook publicaties in de krant automatisch gegenereerd worden. Tevens wordt op basis van documenttypen vastgelegd welke documenten uit het zaakdossier zullen worden gepubliceerd, bijvoorbeeld de aanvraag. Europese aanbesteding , 28 maart

179 => De burgermeester heeft de volgende aanvragen voor een evenementenvergunning ontvangen. => er worden geen documenten gepubliceerd. Door een gerelateerd zaaktype te selecteren => leeg, wordt het verplicht zaken van dit type te koppelen aan een zaak van een ander zaaktype. Denk hierbij aan een bezwaarschrift dat gekoppeld wordt aan een aanvraag vergunning. De autorisaties We onderscheiden de volgende autorisatie-objecten: - beheer zaaktype tbv functioneel beheer, - behandel zaken van dit zaaktype / beheer documenten in dossier / raadplegen beperkt toegankelijke documenten tbv alle behandelaars, - raadplegen zaken van dit zaaktype / raadplegen besloten documenten tbv geïnteresseerden, - buiten behandeling stellen zaken van dit zaaktype tbv sommige behandelaars, - toewijzen zaken van dit zaaktype tbv medewerkers die zaken toewijzen aan behandelaars. Per object zijn zowel medewerkers, organisatieonderdelen, functies, rollen en groepen te selecteren. Daarnaast is er per status een autorisatie-object, zodat het mogelijk wordt voor verschillende statussen verschillende medewerkers te autoriseren. Europese aanbesteding , 28 maart

180 De statussen Elk zaaktype kent minimaal vier statussen, waarvan de eerste drie statussen én de laatste status altijd hetzelfde zijn. Tussen status 3 en de laatste status kunnen extra statussen worden toegevoegd. => status 1: aanvraag vergunning klein evenement ontvangen => status 2: aanvraag vergunning klein evenement aan behandelende afdeling toegewezen => status 3: aanvraag vergunning klein evenement in behandeling genomen => status 4: aanvraag vergunning klein evenement afgehandeld Intern wordt status 2 gepresenteerd als geaccepteerd. Zaken moeten binnen 24 uur na ontvangst door de behandelaars worden geaccepteerd (dus status 2) of geweigerd. In het laatste geval verschijnt de zaak opnieuw in het postintakeoverzicht, waarna men aan de zaak een ander zaaktype moet koppelen. Per status kan men de standaardtekst opgeven die klanten te zien krijgen, als zij aangeven op de hoogte te willen worden gehouden van de voortgang van de zaak. (status 2) => Uw aanvraag voor een evenementenvergunning is ontvangen door de behandelende afdeling. De aangeleverde informatie toetsen wij op volledigheid en wij kijken of de juiste vergunning is aangevraagd. Indien de aangeleverde informatie niet juist of niet volledig is, nemen wij zo spoedig mogelijk contact met u op. De teksten per status worden ook opgenomen in de bijlage van de ontvangstbevestiging. De ontvangstbevestiging Zodra een zaak in status 3 belandt, wordt een document ontvangstbevestiging in behandeling verstuurd. Mocht na het in ontvangstbevestiging na max dagen =>4 genoemde aantal dagen, de zaak nog niet in status 3 zijn beland, dan wordt een document ontvangstbevestiging ontvangen verstuurd. Men kan bij beide ontvangstbevestigingen kiezen voor een generieke ontvangstbevestiging of een zaaktype specifieke ontvangstbevestiging. De relevante besluiten Binnen een zaak kunnen besluiten worden opgevoerd. => vergunning verleend => vergunning geweigerd Door het invoeren van een publicatietekst worden besluiten automatisch gepubliceerd op zowel de website als bij AdviesOverheid. Tevens wordt op basis van documenttypen vastgelegd welke documenten worden gepubliceerd. (vergunning verleend) => Op grond van de Algemene Plaatselijke Verordening Dordrecht (APV) heeft de burgemeester besloten de onderstaande evenementenvergunningen te verlenen. De besluiten liggen voor u ter inzage bij de balie van het Stadskantoor, Spuiboulevard 300. Een belanghebbende kan tegen besluiten, binnen zes weken na verzending aan de aanvrager, een bezwaarschrift indienen bij de burgemeester (Postbus 8, 3300 AA Dordrecht). In spoedeisende gevallen kan de belanghebbende de voorzieningenrechter van de rechtbank te Dordrecht verzoeken een voorlopige voorziening te treffen.. => documenten van het type vergunning worden gepubliceerd. Men kan tevens een reactietermijn => 42 opgeven, waardoor het mogelijk wordt bij de publicatie te vermelden tot wanneer men bezwaar kan maken n.a.v. het besluit. Via een vervolgprocedure kan n.a.v. een besluit automatisch een nieuwe zaak worden opgestart (het besluit een bouwvergunning te verlenen kan bijvoorbeeld automatisch leiden tot een inspectie zaak). Europese aanbesteding , 28 maart

181 De mogelijke resultaten Resultaten en statussen worden vaak door elkaar heen gebruikt. Mozaiek kent een duidelijk onderscheid. Er zijn meerdere statussen, maar een zaak kent altijd maar één resultaat. Zo is aanvraag afgehandeld een status en vergunning verleend een resultaat. => vergunning klein evenement verleend => vergunning klein evenement geweigerd Bij het zetten van de laatste status aanvraag afgehandeld dient men altijd een resultaat te kiezen. Per resultaat kan men de standaardtekst opgeven die klanten te zien krijgen, als zij aangeven op de hoogte te willen worden gehouden van de voortgang van de zaak. => Alle benodigde adviezen zijn ontvangen. De aanvraag is beoordeeld en uw aanvraag kunnen wij toewijzen. De formele beschikking ontvangt u zo spoedig mogelijk per post. Voor nadere informatie, bijvoorbeeld met betrekking tot rechten en plichten, verwijzen wij u naar de website De teksten per resultaat worden ook opgenomen in de bijlage van de ontvangstbevestiging. Naast resultaten, die worden vastgelegd indien de zaak de laatste status heeft bereikt, zijn er ook bijzondere resultaten, waar uit moet worden gekozen, indien een zaak voortijdig wordt afgehandeld. => geen vergunning nodig => aanvraag niet compleet => aanvraag niet tijdig ingediend => aanvraag ingetrokken => dubbel ingeboekt => gewijzigd zaaktype De relevante documenten Een opsomming van documenttypen die kunnen voorkomen in dossiers van dit type zaken. Bij het plaatsen van een document in het zaakdossier is men verplicht het documenttype te kiezen. Het documenttype wordt gehangen aan de relatie tussen het document en het dossier. Hetzelfde document kan immers in een ander dossier een ander documenttype krijgen. =>Aanvraag, Advies, Bijlage bij aanvraag/melding, Bijlage reactie aanvrager, Brief geen vergunning/melding nodig, Brief niet in / buiten behandeling, Intrekking, Ontvangstbevestiging, Rappelbrief, Reactie aanvrager m.b.t. zaak, Verdagingsbesluit, Vergunning, Verslag, Verslag bevindingen, Verslag gesprek, Verzoek om aanvulling, Verzoek om advies, Voornemen, Weigering, Zienswijze De relevante kenmerken per zaak Een opsomming van zaaktype-specifieke kenmerktypen die men kan vastleggen per zaak. => geen zaaktype-specifieke kenmerken De relevante koppelingen registraties in het gegevensmagazijn Er zijn drie bijzondere koppelingen met registraties in het gegevensmagazijn: - aanvrager natuurlijk persoon kan ook een selectie zijn (b.v. 65-plussers) => alle personen - aanvrager niet-natuurlijk persoon kan ook een selectie zijn => alle bedrijven - locatie kan zowel via een koppeling naar het gegevensmagazijn => buurt, wijk, adres, als direct geometrie bij een zaak => punt, vlak, lijn Europese aanbesteding , 28 maart

182 Daarnaast kunnen nog extra relevante koppelingen worden vastgelegd. => geen extra relevante koppelingen Het is te ingewikkeld om alle registraties uit het gegevensmagazijn apart in het model weer te geven. Immers: het moet in de toekomst mogelijk zijn om met álle registraties te koppelen (en dus niet uitsluitend gegevens uit de bekende basisregistraties). Zo zou je idealiter bij een kapvergunning voor een boom de bewuste boom kunnen koppelen. Of bij het melden van een defecte lantaarn, de bewuste lantaarn. Wij hebben dat in Dordrecht opgelost door de verschillende registraties te benoemen. Per registratie bepalen we de identificerende sleutel waarmee we de zaak aan de registratie koppelen. Voorbeeld: zaak x is gekoppeld aan identificerende sleutel y van registratie z. Verplichte documenten per status/resultaat Per status en per resultaat kan worden verplicht dat er een document van een bepaald type in het dossier aanwezig is. Als dit document ontbreekt, kan de status niet worden gewijzigd. (status 2) => Aanvraag (vergunning verleend) => Vergunning (vergunning geweigerd) => Weigering (geen vergunning/melding nodig) => Brief geen vergunning/melding nodig (aanvraag niet tijdig ingediend) => Brief niet in / buiten behandeling (aanvraag ingetrokken) => Intrekking Verplichte kenmerken per status/resultaat Per status en per resultaat kan worden verplicht dat kenmerken een waarde hebben. => geen kenmerken, dus ook geen verplichte kenmerken verplichte koppelingen per status/resultaat Per status en per resultaat kan worden verplicht dat bepaalde extra koppelingen verplicht zijn. => geen extra koppelingen, dus ook geen verplichte extra koppelingen Checklist per status/resultaat Om te kunnen controleren of behandelaars belangrijke stappen in het proces hebben uitgevoerd, kan per statuswijziging een checklist met ja/nee vragen worden vastgelegd. Per ja/nee vraag kan tevens bepaald worden of het antwoord ja verplicht is. De antwoorden worden vastgelegd bij de zaak. (status 3) => Is het zaaktype akkoord? (status 3) => Is de aanvraag volledig? (vergunning klein evenement verleend) => Zijn alle benodigde adviezen aangevraagd? (vergunning klein evenement verleend) => Zijn alle aangevraagde adviezen ontvangen? (vergunning klein evenement verleend) => Is het dossier compleet? (vergunning klein evenement verleend) => Is het besluit gemotiveerd? (vergunning klein evenement verleend) => Is de beschikking door de mandaathouder ondertekend? (vergunning klein evenement geweigerd) => Zijn alle benodigde adviezen aangevraagd? (vergunning klein evenement geweigerd) => Zijn alle aangevraagde adviezen ontvangen? (vergunning klein evenement geweigerd) => Is het dossier compleet? (vergunning klein evenement geweigerd) => Is het besluit gemotiveerd? Europese aanbesteding , 28 maart

183 (vergunning klein evenement geweigerd) => Is de beschikking door de mandaathouder ondertekend? Behandeling zaak Bij het behandelen van een zaak is relevant: - de intake - de taakbak - het wijzigen van de status - het opschorten van de zaak - de naw-gegevens (gegevensmagazijn als basis) - de locatie van de zaak - het zaakdossier - verzoek extern advies - berichten in het zaakdossier - opvoeren besluit - publicaties m.b.t. de zaak - signalen m.b.t. de zaak - opnemen papieren documenten in het dossier - opnemen webdocumenten in het dossier - het verlengen van de zaak De intake De postintake-functionaliteit maakt het de medewerker mogelijk dat: - het juiste zaaktype aan het gescande pdf-bestand wordt gekoppeld, - de naw-gegevens van de aanvrager worden vastgelegd, - algemene en evt. zaaktype-specifieke kenmerken worden veastgelegd, - eventueel de lokatie wordt vastgelegd, - eventueel de gerelateerde zaak wordt vastgelegd, - eventueel een bijlage wordt gekoppeld (bijvoorbeeld a0-tekeningen bij een aanvraag bouwvergunning) middels de zogenaamde scanvelop functionaliteit (zie 2.13). De functionaliteit maakt een zaak en een bijbehorend zaakdossier aan en plaatst de aanvraag en de eventuele bijlage(n) als pdf-document in het dossier. De webintakefunctionaliteit wordt aangeroepen, nadat een klant het webformulier heeft verstuurd. De aangeroepen functionaliteit maakt een zaak en een bijbehorend zaakdossier aan, plaatst de gegevens van het ingevulde webformulier als xml-document in het dossier, plaatst eventuele bijlagen in het dossier, meldt de klant welk zaaknummer is toegekend en via welke url meer informatie over de zaak kan worden verkregen. Het is dus belangrijk dat de webformulier-functionaliteit dit ondersteunt. De aanvraag en de eventuele bijlagen dienen ergens te worden geparkeerd. De aangeroepen functionaliteit haalt de aanvraag en eventuele bijlagen daar op. In Dordrecht versoberen we de webformulieren door uitsluitend webformulier-specifieke gegevens te vragen. De aangeroepen functionaliteit vraagt om generieke gegevens, zoals de naw-gegevens en de vraag of signaleringen per en/of sms gewenst zijn. Europese aanbesteding , 28 maart

184 De taakbak Na de intake heeft de zaak status 1. Via de taakbak worden alle zaken van één zaaktype getoond. Een klik op de omschrijving van een zaak leidt tot het zaak informatie scherm. De kolom st geeft de status van de zaak weer. Status 1 wordt altijd in rood weergegeven, status 2 altijd oranje. De laatste status wordt altijd in groen weergegeven. De overige statussen in geel. De laatste kolom dl geeft de resterende doorlooptijd aan, gebaseerd op de servicenorm. Als er voldoende dagen beschikbaar zijn, wordt deze waarde in groen weergegeven. Bij minder beschikbare dagen wordt deze in oranje of in rood weergegeven. De kolom behandelaar toont standaard de naam van het organisatieonderdeel. Maar medewerkers met toewijs-autorisaties kunnen medewerkers toewijzen aan een zaak. In dat geval wordt de naam van de medewerker getoond. De taakbak bevat tevens een aantal sneltoetsen: - s m.b.t. de signalen (rood betekent dat er ongelezen signalen aanwezig zijn), - w m.b.t. het wijzigen van de status, - o m.b.t. het opschorten van de zaak (oranje betekent dat de zaak nu opgeschort is, rood dat de opgeschorte zaak aandacht behoeft), - d m.b.t. het dossier van de zaak, - a m.b.t. de aanvraag van de zaak, - p m.b.t. publicaties van de zaak (rood betekent dat de zaak nog niet gepubliceerd is), - n m.b.t. nog niet gelezen documenten in het dossier (rood betekent dat er ongelezen documenten aanwezig zijn), - l m.b.t. de locatie van de zaak (rood betekent dat aan de zaak nog geen locatie is gekoppeld). Europese aanbesteding , 28 maart

185 Behandelaars kunnen ook een totaaloverzicht aanroepen met zaken van alle zaaktypen, waarvoor men geautoriseerd is. De taakbak is niet persoonlijk. Behandelaars kunnen dus altijd alle zaken zien. Men kan echter kiezen een selectie van alle zaken te laten zien, bijvoorbeeld alleen die zaken die aan de betreffende medewerker zijn toegewezen. Of alleen de nog niet afgehandelde zaken. Het wijzigen van de status Binnen 24 uur moet de behandelaar de zaak accepteren (wijzigen naar status 2) of weigeren (waarbij de zaak uit deze taakbak verdwijnt en terugkeert naar het postintake-overzicht). Bij het wijzigen van een status kan de checklist met ja/nee vragen verschijnen en een standaardtekst t.b.v. signaleringen naar de klant. Deze standaardtekst kan door de behandelaar nog worden aangepast. Als de zaak ontvankelijk is (de aanvraag is volledig), wordt de zaak in behandeling genomen (wijzigen naar status 3). Bij het wijzigen naar de laatste status, moet tevens een resultaat worden gekozen (bijvoorbeeld vergunning verleend of vergunning geweigerd). Voordat de laatste status is bereikt, kan men ook een bijzonder resultaat kiezen (bijvoorbeeld vergunning ingetrokken of geen vergunning nodig). De zaak wordt dan voortijdig afgehandeld. Europese aanbesteding , 28 maart

186 Het opschorten van de zaak Er kan een reden zijn om een zaak op te schorten, bijvoorbeeld als de klant een onvolledige aanvraag heeft ingediend, als niet alle benodigde documenten zijn meegestuurd. De behandelaar schort de zaak dan op, waarbij het verplicht is de reden op te geven. De opschorting wordt namelijk getoond als de klant de status van de zaak opvraagt. Aan de opschorting wordt geen termijn gehangen. Zodra de aanvraag volledig is, wordt de opschorting beëindigd. Het aantal dagen dat de opschorting duurt, wordt opgeteld bij de standaard doorlooptijd van de zaak. De behandelaar is in staat ter signalering een aantal dagen op te nemen. Als na het ingegeven aantal dagen de opschorting nog niet is beëindigd, krijgt de sneltoets een rode kleur. De naw-gegevens (gegevensmagazijn als basis) Bij de postintake wordt de aanvrager indien mogelijk gekoppeld aan burger- of bedrijfgegevens uit het gegevensmagazijn. Gegevens van de gekoppelde burger of het gekoppelde bedrijf worden als xml-bestand weggeschreven, overigens nog een tweede keer na afhandeling van de zaak (zo ontstaat een zo compleet mogelijk beeld van de aanvrager binnen het dossier, dus los van het gegevensmagazijn). De adresgegevens worden automatisch overgenomen, maar kunnen door de postintakemedewerker worden gewijzigd, indien op de brief andere adresgegevens worden vermeld. De behandelaar ziet in dit geval zowel het correspondentie-adres als het, volgens het gegevensmagazijn, officiële adres. Europese aanbesteding , 28 maart

187 De locatie van de zaak Bij veel zaaktypen is de locatie relevant. Bij de configuratie van het zaaktype wordt vastgelegd of en zo ja, op welke manier, een locatie van een zaak kan worden vastgelegd: - door het koppelen van een adres, - door het koppelen van een wijk, - door het koppelen van een buurt, - door het zetten van een punt, - door het tekenen van een vlak (bijvoorbeeld in het geval van een terrein), - door het tekenen van een lijn (bijvoorbeeld in het geval van een optocht). Er zijn ook combinaties mogelijk. Het zaakdossier Bij het toevoegen van een document aan een zaakdossier dient men allereerst het documenttype aan te geven. Afhankelijk van dit type kunnen extra kenmerken bij het document worden vastgelegd, naast de algemene kenmerken, zoals de naam, de omschrijving, de auteur, eventuele trefwoorden en het publicatieniveau (openbaar, besloten of beperkt toegankelijk). Europese aanbesteding , 28 maart

188 Verzoek extern advies Vanuit het zaakdossier kunnen geselecteerde documenten aan derden worden gestuurd, bijvoorbeeld om advies aan te vragen. Derden ontvangen het verzoek om advies als e- mailbericht. berichten in het zaakdossier Dordrecht gebruikt GroupWise als programma. Relevante berichten kunnen eenvoudig naar Mozaiek worden verplaatst via een speciaal Mozaiek-icoon. De behandelaar kan de naam van het bericht in Mozaiek wijzigen. Door het zaaknummer te vermelden, verschijnt het bericht direct in het juiste zaakdossier. Opvoeren besluit Bij het opvoeren van een besluit zijn vier datums relevant: - datum besluit betreft de datum waarop het besluit is genomen, - datum ingang betreft de datum waarop het besluit geldig wordt, - datum verval betreft de datum waarop het besluit niet langer geldig zal zijn, - datum verzonden betreft de datum waarop het besluit is verzonden naar de klant. De laatste datum is vooral relevant, als er bezwaar kan worden gemaakt. Op basis van deze datum wordt de uiterste datum berekend waarop men bezwaar kan maken. Publicaties m.b.t. de zaak Zaken van een type, waarbij een publicatietekst is vastgelegd, worden op de eigen website en op de website van AdviesOverheid gepubliceerd, zodra de locatie van de zaak bekend is. Afhankelijk van het zaaktype worden ook de aanvraag en/of de bijlagen gepubliceerd. Besluiten binnen de zaak, waarbij een publicatietekst is vastgelegd, worden ook gepubliceerd. Ook hier worden, afhankelijk van het besluittype, documenten gepubliceerd, zodra deze in pdf-formaat beschikbaar zijn. Signalen m.b.t. de zaak De behandelaar kan een signaal vastleggen. Een signaal kan worden beschouwd als een e- mailbericht, gericht aan de zaak en/of medewerkers en/of derden, die niet direct wordt verstuurd, maar op een vooraf opgegeven datum. Een signaal, gericht aan de zaak, verschijnt in de signaalbak van de zaak. Bij een ongelezen signaal wordt de sneltoets in de taakbak rood. Opnemen papieren documenten in het dossier Soms is het gewenst dat een scan van een papieren document in het zaakdossier wordt opgenomen. De behandelaar kan dit eenvoudig realiseren door bij het toevoegen van een document aan een dossier, te kiezen voor de zogenaamde scanvelop functionaliteit. Men voert dan eerst op de gebruikelijke wijze alle kenmerken van het document in, zoals bijvoorbeeld het documenttype. Er verschijnt een voorblad met barcode, dat moet worden uitgeprint en samen met het papieren document moet worden verstuurd. Centraal worden al deze verzoeken gescand, waarna de scan als pdf-document direct in het juiste dossier terecht komt. Totdat het document is gescand, wordt middels een grijs pdf-icoontje duidelijk gemaakt, dat het betreffende document binnenkort gescand zal worden. Europese aanbesteding , 28 maart

189 Opnemen webdocumenten in het dossier Soms is het gewenst om snel een document in het zaakdossier op te nemen, zonder hiervoor een tekstverwerkingsprogramma te hoeven opstarten. Bijvoorbeeld in het geval van een telefoonnotitie. De behandelaar kan dit eenvoudig realiseren door bij het toevoegen van een document aan een dossier, te kiezen voor de zogenaamde webdocument functionaliteit. Men voert dan eerst op de gebruikelijke wijze alle kenmerken van het document in, zoals bijvoorbeeld het documenttype en daarna kan men direct via webfunctionaliteit het document samenstellen. Het document wordt vanuit het dossier als webpagina getoond. Het verlengen van de zaak Wanneer er meer tijd nodig is om een zaak af te handelen, kan in sommige gevallen een verdagingsbesluit worden genomen. De behandelaar kan in zo n geval de zaak verlengen. Net als bij het opschorten van een zaak, moet er verplicht een reden worden opgegeven. De verlenging wordt namelijk getoond als de klant de status van de zaak opvraagt. Aan de verlenging wordt een termijn gehangen, welke wordt opgeteld bij de standaard doorlooptijd zoals deze is gedefinieerd voor het betreffende zaaktype. Europese aanbesteding , 28 maart

190 3. Communicatie met de klant We onderscheiden hier: - communicatie openbare informatie - communicatie met de aanvrager 3.1 communicatie openbare informatie Op de website worden automatisch alle recente aanvragen en besluiten getoond, zodra de lokatie bekend is (vanwege het tonen op een kaart). De te publiceren documenten worden pas getoond, nadat het document in pdf-formaat in het zaakdossier is opgenomen. Vanuit Mozaiek worden ook de publicaties op de landelijke website van AdviesOverheid getoond. Europese aanbesteding , 28 maart

191 3.2 communicatie met de aanvrager De klant krijgt na het versturen van het webformulier en via een ontvangstbevestiging het unieke zaaknummer te zien. Via kan men de status van de zaak opvragen. Er wordt dan tevens getoond hoe het staat met de doorlooptijd, waarbij de uiterste datum wordt genoemd, waarop de gemeente de zaak moet hebben afgehandeld. Hierbij wordt rekening gehouden met eventuele perioden van opschorting en/of verlenging van de zaak. Europese aanbesteding , 28 maart

192 In de ontvangstbevestiging wordt tevens een pincode genoemd, waarmee men meer informatie over de zaak kan krijgen. Hiertoe kan men ook de DigiD code gebruiken. Europese aanbesteding , 28 maart

193 Men krijgt tevens meer mogelijkheden. Zo kan men een adres en/of mobiel telefoonnummer opgeven en aangeven dat men via en/of sms op de hoogte wil worden gehouden van statuswijzigingen m.b.t. de zaak. Europese aanbesteding , 28 maart

194 Ook kan men reageren m.b.t. de zaak door een vraag of opmerking te versturen, eventueel met een document als bijlage. Deze reactie wordt uiteraard direct in het juiste zaakdossier geplaatst. In de taakbak krijgt de sneltoets ongelezen documenten een rode kleur. Europese aanbesteding , 28 maart

195 4. Managementinformatie We onderscheiden: - managementinformatie m.b.t. ingekomen zaken - managementinformatie m.b.t. afgehandelde zaken 4.1 managementinformatie m.b.t. ingekomen zaken Per zaaktype wordt over een bepaalde periode m.b.t. de ingekomen zaken getoond: - hoeveel zaken zijn ontvangen, - hoeveel zaken zijn ontvangen per kanaal, - hoeveel zaken zijn inmiddels afgehandeld, - hoeveel zaken zijn nog openstaand. 4.2 managementinformatie m.b.t. afgehandelde zaken Per zaaktype wordt over een bepaalde periode m.b.t. de afgehandelde zaken getoond: - hoeveel zaken zijn afgehandeld, - hoeveel zaken zijn afgehandeld per initiërend kanaal, - hoeveel zaken per resultaat (bijvoorbeeld vergunning verleend of vergunning geweigerd), - hoeveel zaken zijn op tijd afgehandeld, - hoeveel zaken zijn niet op tijd afgehandeld. Europese aanbesteding , 28 maart

196 Voorbeeldformulier evenementenvergunning Figuur 8.2 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (1/7) Europese aanbesteding , 28 maart

197 Figuur 8.3 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (2/7) Europese aanbesteding , 28 maart

198 Figuur 8.4 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (3/7) Europese aanbesteding , 28 maart

199 Figuur 8.5 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (4/7) Europese aanbesteding , 28 maart

200 Figuur 8.6 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (5/7) Europese aanbesteding , 28 maart

201 Figuur 8.7 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (6/7) Europese aanbesteding , 28 maart

202 Figuur 8.8 Voorbeeld formulier Evenementenvergunning (Gemeente Veghel) (7/7) Europese aanbesteding , 28 maart

203 8.17 Voorbeeldschermen en processen Top-7 producten Aanvragen afschrift GBA Onderstaande beschrijving is een generiek voorbeeld, ter indicatie van het betreffende proces. Het proces aanvragen afschrift GBA kan bijvoorbeeld ook betaling omvatten. Starten website Aanbieden productencatalogus Selecteren Uittreksel GBA Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Versturen a- nummer Scherm 1 Identificerende Gegevens Ophalen adresgegevens postcode tabel Versturen gegevens Scherm 2 Gegevens UIttreksel Gegevens correct? Scherm 3 Controleren gegevens Ja Verzenden en afsluiten Europese aanbesteding , 28 maart

204 Figuur 8.9: beschrijving schermen aanvragen afschrift GBA 42 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Geslacht Versturen a- nummer Voornamen Tussenvoeg sels Achternaam Postcode Huisnummer Huisnummer toevoeging Straatn aam Postcode Ophalen tabel adresgegevens Telefoonnummer overdag opgeven Woonpl aats Versturen gegevens adres opgeven Figuur 8.10 aanvragen afschrift GBA scherm Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

205 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Mogelijke redenen Onderwijs Huwelijk Echtscheiding Afleggen van rijexamen Overschrijven kenteken Anders, namelijk... Kiezen van de reden Internationaal? Nee Ja Aanvraag voor gezinslid? Ja Voornamen Nee Tussenvoeg sels Achternaam Geboortedat um Geboortepla ats Figuur 8.11 aanvragen afschrift GBA scherm Beschrijving afkomstig van EGEM. Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

206 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Ingevoerde gegevens Gegevens correct? Ja Nee Betalen Gegevens invoeren Internetkassa Nee Ja Gelukt? Verzenden en afsluiten Figuur 8.12 aanvragen afschrift GBA scherm Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

207 Verhuizing (binnen- én intergemeentelijk) Melding adreswijziging Melding adreswijziging Medew. BZ B 1. Ontvangst aanvraag Identiteitstoets Twijfel/ vorige bewoner(s) niet uitgeschreven Akkoord Medew. BZ / B 2. Toetsen volledigheid Incompleet/ niet akkoord Medew. BZ B Instellen onderzoek 3. Opvragen aanvullende Uitgaande post Aanvullende gegevens Compleet/ akkoord Wachten op aanvullende gegevens (4 weken) Geen aanvullende gegevens Akkoord/ niet akkoord Aanvullende gegevens Medew. BZ B 4. Beoordelen aanvullende Bezwaar en beroep Uitgaande post Medew. BZ B Binnengemeentelijk 5. Intergemeentelijk/ Intergemeentelijk Medew. BZ B 6. Opvragen persoonslijst Wachten op persoonslijst Uitgaande post2 Persoonslijst Actualiseren binnengem. Actualiseren intergemeentelijke Figuur 8.13: hoofdprocesbeschrijving aanvragen verhuizing 46 Onderstaande formulieren zijn nog twee losse formulieren, deze kunnen voor het komen tot één formulier in elkaar worden geschoven. 46 Procesbeschrijving afkomstig van gemeente Veghel. Europese aanbesteding , 28 maart

208 Figuur 8.14 aanvragen verhuizing binnengemeentelijk (1/2) Formulier afkomstig van de gemeente Veghel Europese aanbesteding , 28 maart

209 Figuur 8.15 aanvragen verhuizing binnengemeentelijk (2/2) Formulier afkomstig van de gemeente Veghel Europese aanbesteding , 28 maart

210 Figuur 8.16 aanvragen verhuizing buitengemeentelijk Formulier afkomstig van de gemeente Veghel Europese aanbesteding , 28 maart

211 Indienen melding openbaar gebied Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Invoeren in melddesk Terugkoppelen naar aanmelder met nr en afd. Inventariseren melding / calamiteit Bepalen urgentie Gevaar samenleving Ja Uitvoeren onderzoek ter plaatse Nee Beveiligen situatie ter plaatse Afhandelen (technische repressie) Terugkoppeling vastleggen Afhandelen in melddesk Afgehandelde melding Figuur 8.17 Procesflow Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

212 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Starten website Tonen productencatalogus Selecteren Melding Leefomgeving Scherm 1 Identificerende Gegevens Ophalen adresgegevens postcode tabel Scherm 2 Soort Melding en Omschrijving Versturen gegevens Scherm 3 Locatie Veroorzaker bekend? Ja Scherm 4 Gegevens Veroorzaker Nee N.V.T. Scherm 5 Toevoegen Bijlagen Gegevens correct? Scherm 6 Controleren gegevens Verzenden en afsluiten Verzenden gegevens Figuur 8.18: Formulierschermen Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

213 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Geslacht Voornamen Tussenvoeg sels Achternaam Postcode Huisnummer Nee Huisnummer toevoeging Straatn aam Postcode Ophalen tabel adresgegevens Telefoonnummer overdag opgeven Woonpl aats Versturen gegevens adres opgeven Wilt u op de hoogte blijven? Ja Controleren alle velden ingevuld Nee Ja Figuur 8.19 Scherm 1 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

214 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Hoofdcategorie klacht/ melding Keuze Subcategorie klacht/ melding Mogelijke keuzes hoofdcategorieën Mogelijke keuzes subcategorieën afhankelijk van gekozen hoofdcategorie Mogelijke categorieën zijn (zie categorieën Enschede): Aangetroffen goederen Afval Bestrating Bodemverontreiniging Bruggen/ sluizen Dieren Geluidsoverlast Gemalen Gemeentelijke begraafplaatsen Gladheid door ijs/ sneeuw Graffiti Groenvoorziening Havens Hondenpoep Lichtmasten/ lantaarnpalen Luchtverontreiniging Overlast Jeugd Parkeren Riolering Speelvoorzieningen Straatmeubilair Verkeerslichten Waterverontreiniging Wegomleidingen Keuze Nadere omschrijving klacht/ melding Mogelijkheid voor toevoegen digitale foto Figuur 8.20 Scherm 2 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

215 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Veroorzaker schade of overlast bekend Ja Straatnaam Huisnummer Huisnummer toevoeging Nee/ NVT Woonplaats Eventueel nadere informatie Figuur 8.21 Scherm 3 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

216 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Veroorzaker schade of overlast bekend Ja Straatnaam Huisnummer Huisnummer toevoeging Nee/ NVT Woonplaats Eventueel nadere informatie Figuur 8.22 Scherm 4 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

217 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Bijlagen meezenden Figuur 8.23 Scherm 5 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

218 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Ingevoerde gegevens Gegevens correct? Nee Ja Verzenden en afsluiten Figuur 8.24 Scherm 6 Melding leefomgeving Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

219 Indienen generiek bezwaarschrift Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) eformulier met bezwaarschrift Registeren bezwaar Opstellen en versturen ontvangstbevestiging Ontvangstbevestiging Beoordelen ontvankelijkheid Ontvankelijk Nee Afwijzen bezwaarschrift Ja Afwijzing Informeren indiener Beroep Akkoord Bepalen rechtstreeks beroep Niet akkoord Opstellen verweerschrift Bepalen vooroverleg bezwarencommissie Vooroverleg Opstellen advies Beoordeeld bezwaar Figuur 8.25 Deelproces Beoordelen ingediend bezwaar Beschrijving afkomstig van EGEM. Europese aanbesteding , 28 maart

220 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Starten website Tonen productencatalogus Selecteren Bezwaarschrift Indienen Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Ja Scherm 1 Identificerende Gegevens Versturen a- nummer Indienen als gemachtigde? Scherm 2 Gegevens Besluit Ophalen adresgegevens postcode tabel Nee Scherm 3 Gegevens Bezwaar Versturen gegevens Nee Scherm 4 Bijlagen meezenden Gegevens correct? Scherm 5 Controleren gegevens Ja Verzenden en afsluiten Verzenden gegevens Figuur 8.26 schermen Indienen Bezwaarschrift Procesbeschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

221 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Geslacht Versturen a- nummer Voornamen Tussenvoeg sels Achternaam Postcode Huisnummer Huisnummer toevoeging Straatn aam Postcode Ophalen tabel adresgegevens Telefoonnummer overdag Woonpl aats Versturen gegevens adres Ja Gemachtigd? Nee Figuur 8.27 scherm 1 Indienen Bezwaarschrift Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

222 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Achternaam Machtiging verlener Geslacht Machtiging verlener Voornamen Machtiging verlener Postcode Machtiging verlener Huisnummer Machtiging verlener Toevoeging Machtiging verlener Straatnaam Machtiging verlener Postcode tabel Ophalen adresgegevens Versturen gegevens Woonplaats Machtiging verlener Telefoonnummer Machtiging verlener adres Machtiging verlener Figuur 8.28 vervolg scherm 1 Indienen Bezwaarschrift Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

223 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Starten website Tonen productencatalogus Selecteren Bezwaarschrift Indienen Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Ja Scherm 1 Identificerende Gegevens Versturen a- nummer Indienen als gemachtigde? Ophalen adresgegevens postcode tabel Nee Scherm 2 Gegevens Besluit en Bezwaar Versturen gegevens Nee Scherm 3 Bijlagen meezenden Gegevens correct? Scherm 4 Controleren gegevens Ja Verzenden en afsluiten Verzenden gegevens Figuur 8.29 scherm 2 Indienen Bezwaarschrift Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

224 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Motivering van het bezwaar Figuur 8.30 scherm 3 Indienen Bezwaarschrift Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

225 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Bijlagen meezenden Figuur 8.31 scherm 4 Indienen Bezwaarschrift 64 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Ingevoerde gegevens Gegevens correct? Nee Ja Verzenden en afsluiten Figuur 8.32 scherm 4 Indienen Bezwaarschrift Beschrijving afkomstig van EGEM Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

226 Aanvragen evenementenvergunning Aanvraag vergunning D&A 0. Inboeken aanvraag Uitgaande post2 Medew. BZ A/B 1. Ontvangst aanvraag Medew. BZ A/B 2. Toetsen Akkoord volledigheid Niet akkoord Medew. BZ A/B 3.Opvragen aanvullende gegs. Uitgaande post4 Evt. Aanvullende gegs. Wachten op aanv. gegevens Medew. BZ A/B Geen aanvullende gegevens Aanvullende gegevens 4.Volledigh.toets aanv. gegs. Niet akkoord Medew. BZ A/B 5. Niet in behandeling nemen Uitgaande post3 Bezwaar en beroep4 Akkoord Archivering Advies BRW Advies Politie Medew. BZ A/B 6. Inwinnen advies Advies Interne afd. Adviezen Wachten op adviezen Medew. BZ A/B 7. Voorleggen aanja B(&W)? Nee Afwikkelen B&W stukken B(&W) besluit Wachten op B(&W) besluit Uitgaande post Medew. BZ A/B 8. Beslissen over vergunning Weigeren Medew. BZ A/B 10. Weigeren vergunning Bezwaar en beroep5 Verlenen Uitgaande post1 Reguliere verificatie Medew. BZ A/B 9. Verlenen vergunning Bezwaar en beroep3 Medew. BZ A/B 11. Archiveren Archivering1 Figuur 8.33: hoofdprocesbeschrijving aanvragen evenementenvergunning 66 Zie verder ook paragraaf Procesbeschrijving afkomstig van gemeente Veghel. Europese aanbesteding , 28 maart

227 Aanvragen gecombineerde BKS-vergunning Aanvragen gecombineerde BKS-vergunning omvat drie sub-zaken: a. Lichte bouwvergunning, b. Kapvergunning en c. Sloopvergunning Vooroverleg Uit gaande post Aanvraag bouwvergunning licht Adm. medew. BWT 1. Ontvangst aanvraag Publicatie Voledigheidstoets Akkoord: geen OAB-procedure Beoordelen bestemmingsplan Niet akkoord of bij twijfel: OAB-procedure Vrijstelings-/ legalisatieverzoeken Wachten op besluit wel of geen medewerking aan vrijstelingsprocedure B&W-besluit wel of geen medewerking aan Geen medewerking Weigeren bouwvergunning Medewerking Beoordelen welstand Akkoord/niet akkoord Beoordelen Bouwbesluit (construc- Beoordelen overige stukken Techn. medew. BWT 2. Tussentijdse beoordeling Geheel, gedeeltelijk niet akkoord Opvragen aanvulende Geen aangepaste aanvraag of aanvulende gegevens niet akkoord Akkoord Akkoord Uit gaande post 1 Techn. medew. BWT 3. Aanhoudingsgronden ja/nee? Techn. medew. BWT Ja 4. Mededelen aanhouding(en) Procedures aanhoudingsgronden Nee Besluit aanhoudingsgrond Wachten op besluit aanhoudingsgrond Techn. medew. BWT 5. Vrijstelingsprocedure ja/nee? Ja Vrijstelings-/ legalisatieverzoeken1 Wachten op B&W-besluit vrijsteling B&W-besluit wel of geen vrijsteling Techn. medew. BWT 6. Tijdige beslissing? Nee Vrijsteling Verlenen van rechtswege Ja Verlenen bouwvergunning Statische berekeningen Handhaving algemeen1 Figuur 8.34: deelprocesbeschrijving lichte bouwvergunning Procesbeschrijving afkomstig van gemeente Veghel. Europese aanbesteding , 28 maart

228 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Starten website Tonen productencatalogus Selecteren Kapvergunning aanvragen Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Scherm 1 Gegevens Aanvrager Versturen a- nummer Indienen als: Huurder/ gemachtigde Scherm 2 Gegevens Eigenaar Locatie Ophalen adresgegevens postcode tabel Versturen gegevens eigenaar Scherm 3 Gegevens Locatie Scherm 4 Gegevens boom of bomen Scherm 5 Bijlagen toevoegen Gegevens correct? Scherm 6 Controleren en afronden Ja Verzenden en afsluiten Verzenden gegevens Figuur 8.35: schermen aanvraag kapvergunning Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

229 Figuur 8.36 Scherm 1 kapvergunning - Uw gegevens 69 Figuur 8.37 Scherm 2 kapvergunning - Eigenaar locatie Beschrijving afkomstig van EGEM Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

230 Figuur 8.38 Scherm 3 kapvergunning - Locatie 71 Figuur 8.39 Scherm 4 kapvergunning - Uit te voeren werkzaamheden Beschrijving afkomstig van EGEM Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

231 Scherm 6 Controleren Scherm 7 Afsluiting Figuur 8.40 Scherm 5 kapvergunning - Bijlagen toevoegen Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

232 Klant Dienstenaanbieder ( eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) eformulier met aanvraag sloopvergunning Bevestiging ontvangst aanvraag Registeren gegevens over sloop Afgehandelde aanvraag Informeren indiener Vastleggen evt. aanwezigheid asbest of andere gevaarlijke stoffen Geen asbest Controleren bewijs van ontbreken asbest Vaststellen sloopmelding of sloopvergunning Sloopmelding Afgehandelde aanvraag Afwijzen aanvraag en informeren indiener Registreren gegevens indiener sloopmelding Registreren gegevens bouwwerk Registreren erkend stortterrein Vrij van asbest Sloop vergunning Informeren indiener; geen sloopvergunning of melding nodig. Informeren indiener over toekenning sloopmelding Bijwerken dossier Afgehandeld verzoek Afgehandeld verzoek 2 Figuur 8.41 Procesbeschrijving Sloopvergunning (deel1) Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

233 Klant eformulier gemeente Centrale Voorzieningen Productaanbieder gemeente 2 Registreren gegevens sloopbedrijf Registreren sloopkosten Registeren sloopmethode Registreren wijze van verwerking sloopafval Registeren asbestverwijdering bedrijf Registreren asbestverwerking bedrijf Geen asbest Registreren gegevens bouwwerk Verstrekken vergunning Afwijzen verzoek Informeren indiener over versterkte vergunning Informeren indiener over afwijzing Bijwerken dossier Afgehandelde aanvraag Afgehandelde aanvraag Figuur 8.42 Procesbeschrijving Sloopvergunning (deel2) Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

234 Klant Dienstenaanbieder (eformulier gemeente) Centrale Voorzieningen Productaanbieder (gemeente) Starten website Tonen productencatalogus Selecteren Sloopvergunning aanvragen Foutmelding DigiD Nee Invullen en opsturen authenticatiegege vens Ontvangen authenticatie gegevens Ja Geldig? Versturen a- nummer Scherm 1 Uw Gegevens Indienen als: Huurder/ gemachtigde Scherm 2 Eigenaar Locatie Ophalen adresgegevens postcode tabel Versturen gegevens eigenaar Scherm 3 Locatie Scherm 4 Sloopwerkzaamhe den Scherm 5 Gegevens bouwstoffenbesluit Scherm 6 Bijlagen toevoegen Gegevens correct? Scherm 7 Controleren en afronden Ja Verzenden en afsluiten Verzenden gegevens Figuur 8.43: schermen aanvraag sloopvergunning Beschrijving afkomstig van EGEM Europese aanbesteding , 28 maart

235 Figuur 8.44 Scherm 4 sloopvergunning 77 Figuur 8.45 Scherm 5 sloopvergunning Afkomstig van EGEM Afkomstig van EGEM Europese aanbesteding , 28 maart

236 Intern proces: in- en uitdiensttreding Manager Adm. medew. P&O 1. Vastleggen afspraken Afdoeningsmandaat 2. Opmaken brief met akte van Man. assistent 3. Verzenden aanstellingsbrief Door manager ondertekende brief, met verzoek opgave Wet Samen in te vullen en retournere Uitgaande post Adm. medew. P&O 4. Invullen Routingsformulier Routingsformulier Aanstellingsbrief + aktie bestemd voor PSA Invoer en mutatie personeels- en Man. assistent 5. Completeren, uitzetten / bewaken Wachten op startdatum (intake z.s.m. na startdatum) Medew. P&O 6. Intake arbeidsvoorwaarden Aanmeldingsformulier IZA Invoer en mutatie personeels- en Adm. medew. P&O 7. Archivering Personeelsdossier Introductie Figuur 8.46: hoofdprocesbeschrijving indienstreding Procesbeschrijving afkomstig van gemeente Veghel. Europese aanbesteding , 28 maart

237 Figuur 8.47 voorbeeld screenshot indiensttreding Screenshot afkomstig van gemeente Venlo. Europese aanbesteding , 28 maart

238 Figuur 8.48 voorbeeld screenshot indiensttreding Screenshot afkomstig van gemeente Venlo. Europese aanbesteding , 28 maart