of Kassasysteem CD000445

conceptnota

Conceptnota Ticketing- en toegangscontrolesysteem en/of Kassasysteem CD000445

Versie 6.1

CD000455_Conceptnota_TikToeKas.docx

Pagina 1 van 13

conceptnota

Inhoudsopgave 1

Doelstelling conceptnota ................................................................................................. 3 1.1 De opdracht ............................................................................................................ 3 1.2 Digipolis .................................................................................................................. 3 2 Opdrachtgevend bestuur, wijze van gunning, motivering, procedure .................................... 3 2.1 Opdrachtgevend bestuur ........................................................................................... 3 2.2 Wijze van gunnen .................................................................................................... 4 2.3 Motivatie van de procedure ....................................................................................... 4 2.4 Procedure die zal gevolgd worden .............................................................................. 4 3 Omschrijving van de opdracht ......................................................................................... 5 3.1 Deelnemers ............................................................................................................. 5 3.2 Doelstelling van hoofdklanten .................................................................................... 5 3.3 Beschrijving van de opdracht ..................................................................................... 6 3.3.1 Perceel 1 ........................................................................................................... 6 3.3.2 Perceel 2 ........................................................................................................... 6 3.4 Duurtijd van de opdracht .......................................................................................... 6 4 Achtergrondinformatie .................................................................................................... 7 4.1 Huidige situatie ........................................................................................................ 7 4.1.1 Perceel 1 ........................................................................................................... 7 4.1.2 Perceel 2 ........................................................................................................... 7 4.2 Toekomstige situatie................................................................................................. 7 4.2.1 Perceel 1 ........................................................................................................... 7 4.2.2 Perceel 2 ........................................................................................................... 7 5 Concept en uit te werken oplossing .................................................................................. 7 5.1 Perceel 1 ................................................................................................................. 7 5.2 Perceel 2 ................................................................................................................. 8 6 Functionele vereisten ..................................................................................................... 8 6.1 Ticketing ................................................................................................................. 8 6.2 Toegangscontrole .................................................................................................... 11 6.3 Kassasysteem ......................................................................................................... 12 7 Gevraagde koppelingen ................................................................................................. 12 7.1 Perceel 1 ................................................................................................................ 12 7.2 Perceel 2 ................................................................................................................ 13 8 Technische vereisten ..................................................................................................... 13 9 SLA ............................................................................................................................. 13 10 Implementatie plan ....................................................................................................... 13 11 Conversie .................................................................................................................... 13

Versie 6.1


Pagina 2 van 13

conceptnota

1

Doelstelling conceptnota

Via deze conceptnota wil Digipolis aan de kandidaten voldoende informatie over de opdrachten meegeven zodat deze kunnen inschatten of men zich wenst in te schrijven en meer concreet of zij zich in de eerste fase van deze opdracht willen kandidaat stellen voor één of beide percelen. Deze conceptnota is louter indicatief en kan het opdrachtgevend bestuur niet verbinden. Het uiteindelijke bestek dat aan de geselecteerde kandidaten zal bezorgd worden, zal de definitieve bepalingen rond deze opdracht bevatten.

1.1

De opdracht

Raamcontract met meerdere leveranciers voor het leveren van diensten, hardware en software voor:

Perceel 1: ·

Aankoop, implementatie, opleiding en onderhoud van een ticketing systeem

·

Aankoop, implementatie, opleiding en onderhoud van een toegangscontrolesysteem

·

Aankoop, implementatie, opleiding en onderhoud van een management systeem voor het ticketingsysteem en de toegangscontrole

·

Leveren van onderhoudsdiensten (incl. SLA) en diensten op afroep voor evolutief onderhoud van het management systeem, het ticketingsysteem en het toegangscontrolesysteem

Perceel 2:

1.2

·

Aankoop, implementatie, opleiding en onderhoud van kassasystemen

·

Aankoop, implementatie, opleiding en onderhoud van een management systeem voor het kassasysteem

·

Leveren van onderhoudsdiensten (incl SLA) en diensten op afroep voor evolutief onderhoud van het kassasysteem.

Digipolis

De Steden en OCMW's van Antwerpen en Gent werken voor wat betreft hun telematica-behoeften sinds 1 oktober 2003 samen in de opdrachthoudende vereniging Digipolis. Digipolis levert diensten op het gebied van informatie- en communicatietechnologie. Dit houdt niet enkel hard- en software in, maar ook geïntegreerde totaaloplossingen in verschillende vakgebieden, waarmee de basistaken zo veel mogelijk geautomatiseerd worden. Digipolis verleent deze diensten aan de Stad Antwerpen en Gent, de lokale politie en het OCMW van de steden Antwerpen en Gent.

2 2.1

Opdrachtgevend bestuur, wijze van gunning, motivering, procedure Opdrachtgevend bestuur

Digipolis (opdrachthoudende vereniging) Generaal Armstrongweg 1 2020 Antwerpen

Versie 6.1


Pagina 3 van 13

conceptnota

Tel. (03) 338 97 39 Fax. (03) 338 79 00 Leidend ambtenaar voor dit bestek: Verstraeten, Wim

2.2

Tel: +32 (0)3 338 97 39

Wijze van gunnen

De opdracht is een opdracht voor diensten in de klassieke sector waarvoor de onderhandelingsprocedure met bekendmaking wordt gehanteerd ten behoeve van het opdrachtgevend bestuur Digipolis. De opdracht omvat 2 percelen die onafhankelijk van elkaar kunnen gegund worden. 2.3 · ·

Motivatie van de procedure De aanbestedende dienst opteert voor het toewijzen van een opdracht van diensten voor de onderhandelingsprocedure met bekendmaking krachtens art. 17, §3,4° van de wet van 24 december 1993 De aanbestedende overheid is immers van mening dat de gunning van onderhavige opdracht niet mogelijk is door aanbesteding noch door offerteaanvraag omdat de technische specificaties van de opdracht op voorhand niet met voldoende nauwkeurigheid kunnen worden bepaald o

o o

de functionaliteiten die de aanbestedende overheid vraagt en vnl. de toekomstige uitbreidingsmogelijkheden moeten getoetst worden aan de bereidheid van de potentiële inschrijvers om te komen tot een oplossing die aansluit bij de noden van de gebruikers; de aanpak van de implementatie van de toepassing moet in overleg met de leverancier worden bepaald; de aanbestedende overheid wil bij de potentiële aanbieders nagaan hoe ondersteuning (opleiding, begeleiding, onderhoud en ondersteuning, …) kan aangeboden worden aan de eindgebruikers

In het licht van het voorgaande is het belangrijk dat in overleg tot concrete afspraken kan gekomen worden zodat de kostprijs van bepaalde functionaliteiten kan afgewogen worden. Hierbij is het belangrijk dat de aanbestedende overheid en de aanbieder gezamenlijk vraag en aanbod op elkaar kunnen afstemmen. In functie van de concrete kosten en baten afweging kunnen dan bepaalde functionaliteiten wel of niet opgenomen worden.

2.4

Procedure die zal gevolgd worden

De procedure die zal gevolgd worden: Verzending Bulletin der Aanbestedingen en Europees Publicatieblad Openbare zittingsdag kandidaatstelling Verzending aan niet-geselecteerden ifv beroepsmogelijkheden Verzending bestek aan geselecteerde inschrijvers Beperkte zittingsdag ontvangst offertes Onderhandelingen Verzending brief aan niet-geselecteerden ifv beroepsmogelijkheden Verzending gunningbrief aan geselecteerde inschrijver

30-04-2012 07-06-2012 27-06-2012 13-07-2012 03-09-2012 Tot 12-11-2012 07-12-2012 24-12-2012

Een toelichtingsvergadering zal plaatsvinden in het Auditorium van Digipolis Antwerpen, op woensdag 16 mei 2012 van 11u00 tot 12u00. Hierbij zal de opdracht toegelicht worden, zullen de al ingediende vragen beantwoord worden, en is er nog de mogelijkheid tot vraagstelling. De aanwezigheid van de inschrijvers is niet verplicht. De procedure van beoordeling onderhandelingsrondes.

Versie 6.1

van

de

inschrijvers

zal


verlopen

in

een

aantal

Pagina 4 van 13

conceptnota

De aanbestedende overheid behoudt zich het recht voor om, in het licht van de concrete noden van het onderhandelingsproces, het verloop van deze onderhandelingen te wijzigen.

3 3.1

Omschrijving van de opdracht Deelnemers

De opdrachthoudende vereniging Digipolis en de leden van Digipolis, zijnde de Stad Antwerpen en de Stad Gent, alsook het OCMW Antwerpen en het OCMW Gent, de lokale Politie en verzelfstandigde entiteiten. Voornoemde partijen zijn aldus te beschouwen als de mogelijke afnemers van dit bestek. In eerste instantie zijn de stedelijke bedrijfseenheid “Cultuur, Sport en Jeugd” en stedelijke bedrijfseenheid “Actieve stad” dienst “Toerisme” van de stad Antwerpen vragende partij voor een nieuw ticketing- en toegangscontrolesysteem en kassasysteem ten behoeve van de cultuurcentra, bibliotheken, zwembaden en musea van de stad en haar partners en van de dienst Toerisme. Cultuur, Sport en Jeugd werkt aan de verdere uitbouw van de culturele en sportieve werking en infrastructuur van de stad. Zij staat in voor de dagelijkse werking van musea, culturele centra en bibliotheken, zwembaden, sportvelden, ... Bovendien regisseert ze het vrijetijdsaanbod voor kinderen, tieners en jongeren in de stad. Zij wil voldoende ruimte in de stad voorzien voor het eigen initiatief van jongeren. Meer info vindt u op: www.antwerpen.be > over de stad > Stedelijke bedrijfseenheden: Cultuur, Sport & Jeugd. Actieve stad wil van Antwerpen de meest aantrekkelijke omgeving maken om te leren, ondernemen, werken, bezoeken en genieten. Onze doelgroepen zijn dan ook alle lerenden, onderwijspartners, ouders, kinderen, jongeren, werkzoekenden, ondernemers, bezoekers, toeristen, horeca, studenten, … Actieve stad omvat de diensten algemeen onderwijsbeleid, Antwerpen Studentenstad, bedrijvenloket, regie kinderopvang, toerisme & congres en werk & economie. Meer info vindt u op: www.antwerpen.be > over de stad > Stedelijke bedrijfseenheden: Actieve Stad.

3.2

Doelstelling van hoofdklanten

De hoofddoelstelling is te komen tot één gecentraliseerd ticketingsysteem, geïntegreerd met een generieke kassasysteem, waarbij verschillende Antwerpse instellingen betrokken zijn. Hieraan wordt een toegangscontrolesysteem gekoppeld. Het kassasysteem dient naast de integratie met onder andere de ticketverkoop ook onafhankelijk van het ticketing/toegangssysteem te kunnen gebruikt worden bv. via een eenvoudige kassa. Hetzelfde geldt voor de ticketing- en toegangssystemen: deze dienen zowel in de volledig geïntegreerde oplossing beschikbaar te zijn, alsook in een eenvoudige variant met beperkte beschikbare functionaliteiten. Verder moet de integratie met getrouwheidssystemen (zoals bv. A-kaart, city-kaart, … ) een centraal klantenbestand mogelijk maken, zodat de communicatie met de klant kan worden geoptimaliseerd. De kassa dient een uniforme interface te voorzien naar een aantal boekhoudsystemen. Verder kan de (operationele) rapportering van de ticket/toegangssysteem uitgebouwd worden zodat de ondersteuning van de dagelijkse operationele werking kan verbeterd worden. Rapportering dient zowel per cultuurcentrum of locatie of beide te ondersteunen. Complexe statistieken dienen te worden getrokken via een datawarehouse. Een belangrijk aspect dat moet worden meegenomen is de dematerialisatie van de tickets.

Versie 6.1


Pagina 5 van 13

conceptnota

3.3

Beschrijving van de opdracht

3.3.1

Perceel 1

De opdracht Ticketing en Toegangscontrole bestaat uit: · ·

Analyse van de functionele en technische realisatie Implementatie van het ticketingsysteem en het toegangscontrolesysteem en de configuratie van de bijbehorende software Opleiding van eindgebruikers en administrators en bijstand tijdens testen door de eindgebruikers Het afsluiten van een SLA voor de ondersteuning en het onderhoud van de systemen en eventueel bijhorende toepassingen

· ·

In de hierna beschreven hoofdstukken zal aangegeven worden wat er in een eerste fase gerealiseerd moet worden en welke uitbreidingsmogelijkheden beschikbaar moeten zijn. De gunning betreft een raamcontract met realisatie van de eerste fase en met de mogelijkheid om gedurende de looptijd van het contract extra diensten of componenten te bestellen ten behoeve van de diensten “Cultuur, Sport en Jeugd” en “Toerisme” of andere mogelijke deelnemers. Hiervoor zal aan de geselecteerde kandidaten ook een producten dienstencatalogus gevraagd worden met gedetailleerde prijszetting. Tijdens de opdracht en het onderhoud zal alle communicatie in het Nederlands verlopen. Alle systeem, opleidingen, documentatie, schema’s, … zullen steeds in het Nederlands aangeboden worden.

3.3.2

Perceel 2

Het onderdeel “Generieke Kassa” uit de opdracht bestaat uit: · · ·

Analyse van de functionele en technische realisatie Implementatie en configuratie van één of meerdere kassasystemen (complexe/eenvoudige) Opleiding van eindgebruikers en administrators en bijstand tijdens testen door de eindgebruikers Het afsluiten van een SLA voor de ondersteuning en het onderhoud van de systemen en eventueel bijhorende toepassingen

·

In de hierna beschreven hoofdstukken zal aangegeven worden wat er in een eerste fase gerealiseerd dient te worden en welke uitbreidingsmogelijkheden beschikbaar moeten zijn. De gunning betreft een raamcontract met realisatie van de eerste fase en met de mogelijkheid om gedurende de looptijd van het contract extra diensten of componenten te bestellen. Hiervoor zal aan de geselecteerde kandidaten ook een producten dienstencatalogus gevraagd worden met gedetailleerde prijszetting. Tijdens de opdracht en het onderhoud zal alle communicatie in het Nederlands verlopen. Alle systeem, opleidingen, documentatie, schema’s, … zullen steeds in het Nederlands aangeboden worden. 3.4

Duurtijd van de opdracht

De duurtijd van het raamcontract bedraagt 4 jaar na implementatie, alle systemen worden gegund met een onderhoud van onbepaalde duur, jaarlijks stilzwijgend te verlengen en te betalen.

Versie 6.1


Pagina 6 van 13

conceptnota

De exacte tijdslijnen voor implementatie van de systemen voor de diensten “Cultuur, Sport en Jeugd” en “Toerisme” zullen deel uitmaken van de onderhandelingsprocedure. Indicatief kan er worden meegegeven dat de systemen operationeel moeten zijn in 2013.

4

Achtergrondinformatie

4.1

Huidige situatie

4.1.1

Perceel 1

Het huidige ticketingsysteem heeft als hart de SRO en itheatre modules. Verder worden getrouwheidsmodules (A-kaart, city-kaart, ….) en zaalreserveringsmodules (bv artifax) gebruikt. Deze systemen staan momenteel los van elkaar en zijn dus niet gekoppeld. Dit heeft als grote nadeel dat er verscheidene klantenbestanden moeten worden onderhouden. 4.1.2

Perceel 2

Vandaag worden een aantal verschillende kassasystemen gebruikt die los van elkaar werken. Op sommige locaties geeft dit problemen, aangezien de verschillende kassa’s niet geïntegreerd werden tot 1 uniforme kassa. Daarnaast werd de huidige kassa onvoldoende geïntegreerd met andere systemen (bv. verzilveren van gespaarde A-kaart punten om een ticket te bekomen e.d.) waardoor toekomstige evoluties moeilijk of onmogelijk zijn. 4.2

Toekomstige situatie

4.2.1

Perceel 1

Een ideale oplossing is een open ticketingplatform, idealiter bestaande uit een aantal functionele modules. Modules kunnen afhankelijk van de wensen en behoeften van de verschillende diensten al dan niet geïmplementeerd worden. Hiermee kan een maximale flexibiliteit bereikt worden. Het toegangscontrolesysteem moet een breed scala aan oplossingen bieden waaronder ook toekomstgerichte. Beide systemen moeten op een eenvoudige manier kunnen gekoppeld worden aan het kassasysteem. 4.2.2

Perceel 2

Het doel is om over een uniforme kassa te beschikken voor alle afdelingen van “Cultuur, Sport en Jeugd” en “Toerisme” te Antwerpen. Op termijn zouden andere geïnteresseerden deze kassa of een variante ook kunnen (her)gebruiken en/of integreren. De ideale toekomstige situatie bestaat uit één of meerdere uniforme kassa’s, waarbij steeds dezelfde interfaces gerespecteerd worden (zowel inkomend als uitgaand) en waarbij de mogelijkheden van de kassa worden bepaald door de locatie en medewerker. De kassa dient zowel fysisch als logisch voorzien te worden (verkoop via website of fysische locatie, bv. zwembad). De kassa (en variantes) dienen zowel geïntegreerd te kunnen worden in één of meerdere business toepassingen (bv. toegang en ticketingsoftware), als alleenstaand voorzien te worden (zoals bv. in een shop). Idealiter worden steeds dezelfde open uniforme interfaces gerespecteerd.

5 5.1

Concept en uit te werken oplossing Perceel 1

Het ticketingsysteem en de toegangscontrole vormen een ondeelbaar geheel. Beiden moeten gekoppeld worden aan andere externe systemen waarvan de belangrijksten het kassasysteem, de A-kaart en de City-kaart zijn. In volgend hoofdstuk worden de functionele vereisten meer in detail belicht.

Versie 6.1


Pagina 7 van 13

conceptnota

5.2

Perceel 2

Conceptueel dient de kassa gekoppeld te worden aan geen/één/meerdere business toepassingen (ticketing/inkom/bibliotheek/shop/…) en backend-systemen, waaronder hoofdzakelijk een aantal boekhoudpakketten (bv SAP, winbooks, exact, …). De kassa dient ondersteund te worden door externe netwerken (digitale betalingen) en getrouwheidssystemen (mogelijkheid om met getrouwheidskaart te betalen ed). De kassa dient zelf over een aantal functionaliteiten te beschikken (niet exhaustief), die in het volgende hoofdstuk beschreven worden.

6 6.1

Functionele vereisten Ticketing

Het ticketingsysteem zal gebruikt worden voor het reserveren en verkopen van tickets voor zowel eigen als niet eigen events en voor de verkoop van andere producten zoals merchandising en cadeaubonnen. Volgende functionaliteiten (niet-exhaustief) zijn zeker aanwezig: · Tickets op naam of regulier · Genummerd of niet-genummerd · Ingeval van genummerde tickets, gekoppeld aan een zaalplan · Een onbeperkt aantal prijstypes per dienst o Individueel o Abonnement o Combi-tickets o Korting o A-kaart o Acties o ... · Financiële en andere rapporten per dienst · Verkoop van tickets: o Balie o Telefonisch o Internet (incl sociale media) o E-mail o Sms o Automaat o ... · Gecombineerde verkoop van tickets via “package-verkoop” dient ondersteund te worden (bv museumticket met gids rondleiding, ticket met logiesreservatie, …)

Versie 6.1


Pagina 8 van 13

conceptnota

De verschillende balies in de diensten hebben specifieke functionaliteiten nodig: · Afdrukken van tickets · Betalingswijzen: o Contant o Credit card o Bancontact o Proton o Overschrijving met gestructureerde mededeling o Factuur o Credits op de A-kaart o ... · Een duidelijk verkoopsscherm met: o Bestelling o Wijzigingen in de bestelling o Terugname o Ruil o Betalingswijze o Aanpassing van aantallen in reservering o ... · Opvolging van de ticketverkoop en opvragen van overzichten met volgende informatie (niet-exhaustief): o Aantal beschikbare tickets per evenement o De ingenomen plaatsen o De uitgereikte vrijkaarten o Verkochte, bestelde en gereserveerde kaarten o Kortingkaarten o Plaatsen via abonnementen o ... · Automatische opmaak van facturen · (Automatisch) verzenden van betalingsgegevens · Automatische aanmaak van gestructureerde overschrijvingen · Zoekfuncties op alle verschillende gegevens · ... Onlineverkoop van tickets moet mogelijk zijn: · Integratie van webinterface in de websites van de respectievelijke diensten · Weergave van zaalplan voor genummerde tickets · Betalingsmogelijkheid via betaalkaarten · Klantenlogin, geïntegreerd met de A-kaart of combinatie van e-mailadres met zelfgekozen wachtwoord Het printen van tickets moet niet alleen aan de balie, maar ook thuis kunnen gebeuren. Een toegangscontrolesysteem op de thuis afgeprinte tickets wordt voorzien/beschreven door de aanbieder. Tickets en rapporten moeten kunnen worden afgeprint in front en back office: · Klassieke tickets · Tickets met barcode · E-tickets · Barcode op smartphone · Brieven · Adresetiketten · Routebeschrijvingen · Extra bonnen · ... Het printsysteem moet zowel geschikt zijn voor individuele printopdrachten van verschillende formaten en lay-outs, als voor bulk printing.

Versie 6.1


Pagina 9 van 13

conceptnota

Alle culturele instellingen werken met één centraal klanten- en relatiebestand. Dit sluit niet uit dat ook het opzetten van meerdere databanken mogelijk is. Het systeem laat toe om gegevens van klanten bij te houden: niet alleen persoonlijke gegevens maar ook een historiek van bijgewoonde evenementen en een historiek van marketingactiviteiten waarbij de klant betrokken werd. Verwacht wordt dat minimaal volgende gegevens per klant/relatie geregistreerd worden: · Naamgegevens, zowel voor individuele klanten als voor groepen (bedrijven, scholen, verenigingen, ...) · Meerdere adressen: woonplaats, afleveradres, facturatieadres, ... · Individuele personen kunnen linken aan één of meerdere bedrijven/scholen/... · Aanduiden naam van een voorkeurcontact voor bedrijf/school/vereniging/... · Type klant · BTW nummer · Nummer A-kaart · Voorkeuren · Verkoopshistoriek · Mailing en communicatiehistoriek · Extra informatie per klant De klant zal een aantal van de gegevens online zelf kunnen inbrengen en beheren. Hiervoor zal een integratie dienen te voorzien worden met de A-kaart of (indien de klant geen A-kaart heeft) een login en wachtwoord per klant nodig zijn. Ze zijn dan in staat om persoonlijke gegevens en interesses en/of voorkeuren in te brengen en te wijzigen. De administratieve medewerker en/of systeembeheerder kan het volledige klantenbestand beheren: · Wijzigingen aanbrengen aan de data en een interface voorzien voor updates met de CRMsystemen (A-kaart, …). · Dubbele registraties van eenzelfde klant samenvoegen, zowel manueel als automatisch · Samenstellen van klantenlijsten voor statistiek en mailings. Een gerichte communicatie aangaande evenementen is noodzakelijk, daarom dient er een open en generieke interface te zijn met de CRM-modules. Deze dient onder andere volgende communicatie te ondersteunen : · Geadresseerd drukwerk · Elektronische nieuwsbrieven · E-mail (real-time) · Sms (real-time) · Direct mailing: o Algemeen of gepersonaliseerd o Individuen of specifieke groepen · Templates per dienst conform de huisstijl · ... Alle gegevens opgeslagen in de databank moeten kunnen worden geanalyseerd. Hiervan moet rapporten en statistieken worden gemaakt voor operationeel gebruik, beleidsondersteuning en adhoc- vragen: · Operationeel o Dagelijkse rapporten o Periodieke rapporten (wekelijks, maandelijks, trimestrieel, ...) o ... · Beleidsrapportering o Rapporten voor de Vlaamse overheid o Programmatiebeslissingen o Organisatorische beslissingen o ... · Adhoc-vragen

Versie 6.1


Pagina 10 van 13

conceptnota

Alle data moet op een eenvoudige manier te exporteren zijn naar bv. Excel of naar een datawarehouse systeem zoals Cognos. Import van bv. klantengegevens moet mogelijk zijn vanuit diezelfde systemen. Een aantal systeem setups en parametrisaties moeten door bepaalde medewerkers van de verschillende diensten zelf kunnen worden uitgevoerd zonder tussenkomst van de leverancier: · Ontwerpen van zaalplannen · Beheer van alle evenementen · Beheer van prijstypes, templates, print opties, ... · Aanmaken van de ticket layout · Aanmaken van gebruikersrechten en groepen · Aanmaken van rapporten · Opzetten van beveiligingen · Definiëren van scherm layouts per balie · Naamgeving van velden volgens de eigen interne nomenclatuur · Beheren van de klantendatabank · ... Een extra functionaliteit “gidsentoekenning” dient voorzien te worden. Deze dienst moet gekoppeld worden aan bestaande paketten van de dienst “Actieve stad, Toerisme en Congres” of geïntegreerd worden in het ticketingsysteem en heeft volgende functionele vereisten: · Gidsenbestand waar alle info beheerd wordt van gidsen waarmee wordt of werd samengewerkt · Gidsen kunnen worden ingepland door de planningsverantwoordelijke m.b.v. een selectie op alle mogelijke filtercondities · Op basis van beschikbaarheid en vaardigheden kunnen gidsen worden gekoppeld aan activiteiten. Vaardigheden zijn oa: o Taal o Kennis o Doelgroep o ... · Ingeplande gidsen moeten zelf online voorstellen van opdrachten kunnen bevestigen · Online agendabeheer (beschikbaar / niet beschikbaar) gidsen · Duidelijke en flexibele rapportering vanuit het systeem · ... 6.2

Toegangscontrole

De toegangscontrole kan opgesplitst worden in twee delen: validering van de tickets op gelijk welke wijze en de eigenlijke mechanische toegang. Voor de validering van de verschillende tickets kunnen volgende systemen (niet-exhaustief) worden ingezet: · Klassieke barcodelezers · 2D barcodelezers · Klassieke badgelezers · Insliklezers · e-Idlezers · RFID-lezers (actief en passief) · Biometrische lezers · ... Voor de mechanische toegang kunnen volgende oplossingen (niet-exhaustief) worden ingezet: · Tourniquets · Driepikkels · Speedgates · Slagbomen · ... Evenementen worden geregeld op locatie georganiseerd, zowel de ticket- als toegang- als kassasystemen dienen dit te ondersteunen.

Versie 6.1


Pagina 11 van 13

conceptnota

6.3

Kassasysteem

De kassa (in de complexe vorm) dient te kunnen beschikken over volgende functionaliteiten (niet exhaustief): Hoofd- en bijkassa Geldlades uitwisselen/verwisselen Registratie Kassa “lezen”, verrichtingen opzoeken, flexibel rapporteren & flexibel afsluiten Omgaan met wisselgeld & opzoeken van (mogelijke) foute teruggave(s) bij kassaverschil Automatisch wisselgeld berekenen Corrigeren van transacties tot 1 maand na datum (geen roll-back) Annuleren van een transactie in real-time. Product-cataloog (zowel voor randsystemen als voor stand-alone kassa) over de bedrijven heen. Product dient ook aan te geven of speciale betalingsfaciliteiten toegestaan zijn of niet (maaltijdcheques bv.). Automatisch berekenen van de totaalprijs Print betalingsbewijs & transactiebewijs Correcte prijs berekenen en omgaan met verschillende vormen en types korting, in de vorm van : o kortingsbon (bv. 3 euro korting), o kaart (bv. -5%) , o getrouwheidskaart (bv. 10+1), o reductiekaart (bv. 65+) o A-werknemer (of andere corporate loyalty/advantage, …) o Tijdelijke promotie/acties o … Betaalfaciliteiten: o Cash, enkel Euro (geen vreemde munten): § manueel § via cash-betaalautomaat [schema interface Pay-01] § betaalautomaat (volledig automatisch) § optionele volledig automatische kassa (geld in, wisselgeld uit) o Betaalkaart (Maestro, BC/MC, Visa, Mastercard, American Express, …) [schema interface Pay-01] o Cheques (cultuurcheques, studentencheques, maaltijdcheques, …) o Bonnen: cadeaubon, waardebon, … o A-Kaart (betalen met gespaarde punten / inwisselen) [schema interface Pay-02] Boekhoudkundige verwerking / output via “doorgeefluik” : juiste transactie (of deel van transactie) doorgeven aan juiste boekhoudsystemen via generieke en open interface: o Winbooks [schema interface Out-01] o SAP [schema interface Out-01] o … Idealiter wordt de kassa aangeboden (via productcataloog) in bovenstaande complexe vorm en in eenvoudigere vorm (bv voor een shop) waarbij een deel van de functionaliteiten beschikbaar zijn, al dan niet om samen te werken met een externe business toepassing (via generieke open interface).

7 7.1

Gevraagde koppelingen Perceel 1

Zoals reeds beschreven in vorige paragrafen dient er een koppeling te worden voorzien met een aantal bestaande en nog te bouwen externe systemen. Gelet op toekomstige uitbreidingen en nieuwe ontwikkelingen, moet deze koppeling en bijgevolge de interface zo open en transparant mogelijk zijn. · Generieke open koppeling met het kassasysteem · Generieke open koppeling met de A-kaart · Generieke open koppeling met de City-kaart

Versie 6.1


Pagina 12 van 13

conceptnota

· · 7.2

Generieke open koppeling met een Datawarehouse ... Perceel 2

Zoals reeds eerder in dit document aangegeven dient de kassa een koppeling te voorzien: · Generieke open koppeling met business toepassing (ticketing, bibliotheek, inkom, …) · Generieke open koppeling met meerdere business toepassingen (aantal verkoopssytemen samen die 1 kassa integreren om 1x af te rekenen) · Generieke open koppeling met logische verkoopskanalen (bv. website plugin ed) · Generieke open koppeling met loyalty-systeem (vandaag bv. A-kaart) · Generieke open koppeling met externe netwerken (bv. Maestro/Visa/…) · Generieke open koppeling met boekhoudpakketten (vandaag bv. SAP, winbooks, exact, …) · Generieke open koppeling met een Datawarehouse · …

8

Technische vereisten

Technische vereisten zijn afhankelijk van de gekozen oplossing.

9

SLA

Een SLA is op te stellen door de aanbieder. Dit vormt een onderdeel van de beoordeling van de offerte onder de modaliteiten beschreven in het bestek. De volgende diensten moet in een dergelijk contract afgesproken worden: · · · · · · · ·

Preventief onderhoud van de apparatuur om defecten te vermijden en de levensduur te verlengen Helpdesk: uniek contact voor de diensten “Cultuur, Sport en Jeugd” en “Toerisme” voor het ingeven van defecten, stellen van vragen, … Correctief onderhoud: diagnosticeren en herstellen van defecten Evolutief onderhoud: uitvoeren van upgrades, patches, … On-site support: op vraag van van de diensten “Cultuur, Sport en Jeugd” en “Toerisme” moet het mogelijk zijn om on-site ondersteuning te vragen bv. als er een nieuw toegangscontrolesysteem moet worden geïnstalleerd, ... Opleiding op afroep: ook na definitieve oplevering kunnen de diensten “Cultuur, Sport en Jeugd” en “Toerisme” op afroep vragen om extra opleidingsessies te voorzien voor nieuwe medewerkers en/of administrators Rapportering Escalatieprocedure

Voor wat betreft het oplossen/herstellen van fouten zowel voor wat betreft de software als de hardware moeten er zogenaamde alarmniveaus afgesproken worden. Het niveau is afhankelijk van de impact van de fout op de organisatie en is verbonden met een maximum response tijd.

10 Implementatieplan Op te stellen door de aanbieder. De kwaliteit van het plan van aanpak vormt onderdeel van de beoordeling van de offerte onder de modaliteiten beschreven in het bestek.

11 Conversie Het huidige systeem dat door de verschillende diensten wordt gebruikt, is SRO3. De conversie van deze data naar het nieuwe systeem is noodzakelijk. De aanbieder stelt een conversiestrategie voor.

Versie 6.1


Pagina 13 van 13

of Kassasysteem CD000445

Recommend Documents