Svar på spørgsmål stillet i forbindelse med billetleverandør udbud i Musikhuset Aarhus.

Transkript

1 Svar på spørgsmål stillet i forbindelse med billetleverandør udbud i Musikhuset Aarhus. 1. Kravspecifikationen: Funktionalitet 1.1 Bedst mulig brugerfunktionalitet for online kunder 6 Ø Systemet skal kunne vise en grafisk model af Musikhusets sale, hvor kunden selv kan vælge sin plads i salen. Grafikken skal give kunden en visuel fornemmelse af salens opbygning og prisindeling samt kvalitet af sæder gerne med kameravinkler og fixpunkter. Skal det være muligt at vælge sæde ud fra billede fra salen, eks. via gallerivisning? Ja, det ville være en fin løsning, der vil vægte i pointgivningen. Men det er ikke et ultimativt krav Ø Systemet skal indeholde en interaktiv seat map (ISM), hvor onlinekunden tidligt i købsprocessen kan overskue, hvor i salen der findes ledige pladser og til hvilken pris. Betyder dette, at MHA ønsker en 3D gengivelse af salene? Eller kan interactive seat map også være en 2D fremstilling af en given sal med interaktiv information? En interaktiv seat map kan enten være en 2D eller en 3D fremstilling af en given sal med interaktiv information. 3. Kravspecifikationen: 1.2 Bedst mulig brugerfunktionalitet for billetsalgspersonalet 36 Ø Systemet skal nemt kunne identificere kernekunder som abonnementer og partoutkortindehavere, evt. via et flag. Skal det være muligt at oprette og navngive nye flag? Ja, men i samarbejde med tilbudsgiver.

2 4. 19 Ø Systemet skal kunne sende et link til en webreservation direkte til kundens adresse via boxoffice modulet. Betyder det, at kunden skal kunne tilgå en reservation? Skal kunden kunne afvise eller acceptere reservationen eller er det for at kunden skal kunne betale en reservation? Det betyder, at kunden skal kunne tilgå sin reservation og betale den via linket Ø Det skal som minimum være muligt at vælge transaktionsformerne fakturasalg, kontant, bankoverførsel, gavekort og kreditkort ved salg af billetter. Der skal kunne vælges mere end en transaktionsform af gangen. Menes der hermed, at den samme transaktion skal kunne sættes til at have været flere forskellige betalingsformer på én gang, eller at forskellige dele af transaktionen, skal kunne sættes til forskellige betalingstyper? Det betyder, at den samme transaktion skal kunne have mere end en betalingstype, fx gavekort og kreditkort, hvis kunden ønsker at betale på denne måde. 6. Kravspecifikationen: 1.3 Bedst mulig administration for Musikhuset 20 Ø Musikhuset administrerer events for flere forskellige promotere, både interne og eksterne. Der skal derfor kunne oprettes en promoter på et event, hvortil afregningen sker direkte, når eventet er overstået. Skal det være muligt at gebyrer afregnes til Musikhuset, og omsætning direkte til ekstern arrangør? Ja, det skal være muligt.

3 7. 19 Ø Systemet skal indeholde et sletteværktøj med mulighed for at slette events og produkter uden transaktioner. Det er normalt ikke muligt eller hensigtsmæssigt at slette først oprettede og forbundne data i noget databasesystem. Vil en arkivering af events og produkter, så de forsvinder for brugeren rent visuelt, accepteres som en sletning? Ja, det vil det, selvom vi ikke ser nogen grund til, at en event eller et produkt uden transaktioner ikke skal kunne slettes Ø Det skal være muligt at definere keywords for en event. Kan keywords uddybes? Menes der keywords til søgning på Internettet, eller internt i billetsystemet for MHAs medarbejdere? Begge dele Ø Systemet skal automatisk kunne gentegne partoutkort fra en sæson til en anden. Kan MHA uddybe partoutkort? Er det en fri adgang til alle events året igennem? Hvis ikke, hvad gentegnes ved et partoutkort? Er det billetter? Er det bestemte billetter, eller er det en serie? Er et partoutkort kun til en kunde? Partoutkort er knyttet til en serie med faste forestillinger. Partoutkortkunder har de samme pladser i salen hvert år/sæson, og derfor skal der kunne gentegnes automatisk. En partoutkortkunde kan have mere end en fast plads pr. sæson. Partoutkortet er ikke personligt. 10. Kravspecifikationen: 1.4. Integration med KMD Opus, kassesystem og andre 3. parts systemer 4 Ø Musikhuset ønsker fuld integration med kasseregistreringssystemet. Kasseløsningen skal være nem og fleksibel sådan, at den kan designes til de produkter Musikhuset sælger, fx billetter og P-kort. En sådan løsning vil minimere fejlregistreringer i

4 forbindelse med salg og tilgodeser det behov Musikhuset har, når der er mange kunder der skal betjenes hurtigt og effektivt. Forsiden på kassen skal kunne designes sådan, at Musikhuset altid kan opsætte kassen, så den passer til det aktuelle behov. En integration til 3. part POS system kan ske på en række forskellige niveauer. Såfremt der skal tilbydes billetsalg med sædevalg og fuldt udvalg af billettyper er dette en ekstremt kompliceret integration, mens at åbne for produktsalg kan være en mere simpel integration. Er der mulighed for at svare dette ønske på forskellige niveauer, evt. ved en opdeling af ønsket? Der skal ikke nødvendigvis leveres et nyt separat kassesystem, det er op til byder. Men der skal fra billetsystemet være en kasseregistrering, fx ved at brugeren/medarbejderen i billetsalget logger sig ind, systemet logger brugerens salg/transaktioner, og det herefter er muligt efter endt arbejde at trække en rapport over brugerens transaktioner, således der kan laves en kasseopgørelse. MHA har behov for at medarbejdere i billetsalget hurtigt, effektivt og med minimum af fejl kan gennemføre billetsalg med sædevalg og fuldt udvalg af billettyper, og salg af fx P- kort. Kan byder opfylde dette behov på anden måde end beskrevet i eksemplet, er MHA åben for andre løsninger. Vi forstår ikke helt dette punkt. Skal det forstås således at der skal leveres et separat kassesystem, eller integreres til et system MHA allerede har? Eller er det kassen i billetsystemet og hvis det er tilfældet, kan MHA uddybe hvad der menes hermed? Der skal ikke nødvendigvis leveres et nyt separat kassesystem, det er op til byder. Men der skal fra billetsystemet være en kasseregistrering, fx ved at brugeren/medarbejderen i billetsalget logger sig ind, systemet logger brugerens salg/transaktioner, og det herefter er mulig efter endt arbejde at trække en rapport over brugerens transaktioner, således der kan laves en kasseopgørelse. MHA har behov for at medarbejdere i billetsalget hurtigt, effektivt og med minimum af fejl kan gennemføre billetsalg med sædevalg og fuldt udvalg af billettyper, og salg af fx P- kort. Kan byder opfylde dette behov på anden måde end beskrevet i eksemplet, er MHA åben for andre løsninger.

5 11. 1 Ø Systemet skal have integration med Århus Kommunes Økonomisystem. Århus Kommunes benytter SAP-systemet KMD Opus som økonomisystem. Der kan på et senere tidspunkt blive stillet krav om integration mod Serviceplatformen. Kan MHA definere eller uddybe Serviceplatformen, såfremt det ikke er det samme som KMD Opus? Landets kommuner arbejder i øjeblikket via KOMBIT med integration mellem økonomisystemer og Serviceplatformen, således at alle kommunale fagsystemer via Serviceplatformen har en snitflade mod alle Økonomisystemer. Dette skal give kommunerne en uafhængighed i forhold til Økonomisystemer, og standardisere snitflade ned mod alle fagsystemer. 12. Kravsspecifikationen: 1.5. IT-mæssige krav, herunder implementering af nyt system. Aarhus Kommune vil på et tidspunkt tage Serviceplatformen i brug i forhold til økonomisystemet KMD Opus. Ønsket betyder, at Musikhuset på et tidspunkt i kontraktperioden kan have behov for at skifte direkte integration med KMD Opus ud med en integration mod KMD Opus via Serviceplatformen. Serviceplatformen er yderligere beskrevet i: og b. Implementering af nyt system 2 Ø Historiske data skal genanvendes i det nye system minimum 5 år, fx oplysninger fra kundedatabasen. 3 Ø Konvertering til et nyt system skal foretages af tilbudsgiver i et direkte samarbejde med Musikhusets nuværende leverandør, Billetlugen. Musikhuset formidler dette samarbejde. 4 Ø Tilbudsgiver skal deltage i en analysefase, hvor det beskrives, hvorledes eksisterende data fra den nuværende løsning kan konverteres til det tilbudte system. Såfremt det gennem analysefasen viser sig, at der er data, der ikke kan konverteres med samme funktionalitet som i det nuværende system, skal der efterfølgende redegøres specifikt for, hvilken funktionalitet der mangler, og hvordan dette tænkes løst. Tilbudsgiver skal beskrive hvordan dette analysearbejde tænkes gennemført.

6 5 Ø Det nye system skal implementeres og testes samtidig med, at det gamle system er i drift. Alle aktive data fra eksisterende system skal genanvendes i det nye system. Det gælder for, men ikke begrænset til følgende data: - Events - Bestilte og købte billetter - Sædehistorik - Kundedata 6 Ø Tilbudsgiver skal lave en implementeringsplan. Planen skal som minimum indeholde tidsplan, beskrivelse af aktiviteter og forventet ressourceforbrug for Musikhuset. Implementeringsplan indskrives i bilag C4, C6 i forbindelse med kontraktunderskrivelse 7 Ø Tilbudsgiver skal i samarbejde med Musikhuset foretage en installations- og driftsprøve. Formålet med prøverne er at konstatere, om samtlige enheder fungerer, og at samtlige øvrige ydelser er leveret i overensstemmelse med kontrakten. Tidspunkt og plan for gennemførelsen af installations- og driftsprøve skal beskrives og indskrives i bilag C4 i forbindelse med kontraktunderskrivelse. 8 Ø Tilbudsgiver har ansvaret for, at der forud for prøvernes afholdelse udarbejdes en drejebog for gennemførelse af installations- og driftsprøven. Drejebogen skal godkendes af Musikhuset. Musikhuset har ansvaret for at konstatere, om prøverne er korrekt gennemført. 9 Ø Installations- og driftsprøverne skal omfatte funktions- og integrationsprøver. Funktions- og integrationsprøverne skal vise, at de leverede enheder/software fungerer som beskrevet i kravspecifikationen og tilbudsgivers dokumentation. Det skal endvidere eftervises, at systemet som helhed fungerer i overensstemmelse med minimumskravet og opfyldte ønsker i kravspecifikationen. Der skal gennemføres en svartidsprøve som led i driftsprøven. Formålet med svartidsprøven er at kontrollere, at systemet overholder de krav til svartider, som er aftalt. 10 Ø Tilbudsgiver skal angive om leverandøren står for opdatering af eventuelle klienter. 11 Ø Eventuel klient skal kunne udrulles med deploymentværktøj, der benyttes af Aarhus Kommune. Pt. benyttes Alteris. 12 Ø Tilbudsgiver bedes angive, om der stilles specielle krav til netværk, åbning gennem firewall for at applikationen kan afvikles på de computere der skal kunne tilgå Systemet jf. Kundens IT-miljø. Nuværende leverandør formodes at kunne svare disse ønsker med "ikke relevant"? Nuværende leverandør skal svare på spørgsmålene vedrørende installations- og driftsprøve for at sikre, at de fortsat har den forventede funktionalitet, ligesom svartider/performence bliver synlig i driftsprøven.

7 13. e. Integrering af Musikhusets hjemmeside 24 Ø Musikhuset har indgået kontrakt med Aarhuskontoret, der står for design af vores hjemmeside: Hjemmesiden er lavet i Umbraco: Hjemmesiden forventes i drift medio august Hjemmesiden implementeres i Q Musikhuset ønsker, at et nyt System kan integreres fuldt ud med Musikhusets hjemmeside, således der kan modtages og sendes data mellem Musikhusets hjemmeside og billetudbyder, og således at indhold kun skal redigeres ét sted. Data skal kunne eksporteres/importeres i et standardiseret format som f.eks. xml eller json. 25 Ø Den tilbudte løsning skal stille en API til rådighed for integration fra Musikhusets hjemmeside. 26 Ø Musikhuset ønsker, at Tilbudsgiver kan tilbyde, at Musikhusets events kan præsenteres i Systemet. Musikhuset skal kun vedligeholde information om events ét sted. Både rådata om arrangementet og de data som løbende beriger arrangementet i form af tekst, billeder og videoer. Det skal forstås således, at Musikhusets medarbejdere kun skal indtaste og redigere oplysningerne ét sted. Herefter skal systemerne udveksle data, således at relevant data præsenteres overfor Musikhusets brugere uanset om de benyttes Tilbudsgivers System eller Musikhusets hjemmeside. 27 Ø Tilbudsgiver skal stille API til rådighed for integration fra Musikhusets hjemmeside mod systemet. 28 Ø Tilbudsgiver skal være behjælpelig med implementeringen af Musikhusets nye hjemmeside. Musikhuset ønsker en beskrivelse af i hvilket omfang Tilbudsgiver kan være behjælpelig og i hvilket omfang det er omfattet af tilbuddet. 29 Ø Tilbudsgiver skal beskrive, i hvilket omfang Open Source tænkes anvendt i løsningen. 30 Ø Musikhuset lægger vægt på, at Løsningen skal anvende markedsudbredte og modne teknologier. Beskriv hvorledes. 31 Ø Musikhuset lægger vægt på, at Systemet skal være fleksibelt opbygget, og skal kunne modificeres med hensyn til design og funktionalitet i takt med, at efterspørgsel og behov ændres i løsningens livscyklus. Beskriv hvorledes. 32 Ø Musikhuset lægger vægt på, at opbygningen af Systemet sikre en høj robusthed mod tab af data og nedbrud i øvrigt. Beskriv hvorledes. 33 Ø Musikhuset lægger vægt på, at Systemet skal fungere i overensstemmelse med de lokale systemer og teknologier, der eksisterer i Musikhuset.

8 Det er med det givne grundlag vanskeligt at vurdere grænseflade mellem Systemet og MHAs nye hjemmeside. Kan der fremsendes dokumentation for den nye hjemmeside, således at der kan svares mere konkret på disse ønsker? Tilbudsgiver er velkommen til at kontakte Aarhuskontoret, Digital Art Director Daniel Wiklund, mobil: , for yderligere information Ø Det nye system skal implementeres og testes samtidig med, at det gamle system er i drift. Alle aktive data fra eksisterende system skal genanvendes i det nye system. Det gælder for, men ikke begrænset til følgende data: - Events - Bestilte og købte billetter - Sædehistorik - Kundedata Kan MHA uddybe hvad Sædehistorik betyder? Al den historik der er knyttet til et sæde, såsom handlinger (reservation/salg/tilbagekøb), samt tidspunkt og brugere knyttet til de forskellige handlinger. Handlingerne skal listes kronologisk Ø Musikhuset lægger vægt på, at Systemet skal fungere i overensstemmelse med de lokale systemer og teknologier, der eksisterer i Musikhuset. Dette er et meget bredt formuleret krav og det kan være svært at tilsige dette som tilbudsgiver, uden at kende de systemer. Kan MHA liste og beskrive alle de systemer, som MHA benytter sig af og som man ønsker at tilbudsgivers system skal fungere i overensstemmelse med? Kan MHA uddybe overensstemmelse? Ønsket skal ses i kontekst af bilag 7: Aarhus Kommunes IT-miljø. Det betyder, at Musikhuset Aarhus ønsker oplyst, om nuværende printere i Musikhuset kan benyttes, om medarbejderne, hvis de skal tilgå systemet via browser kan benytte standard browseren Internet Explorer 9, om 4 GB RAM forventes at være nok til at køre applikationen vel vidende at brugeren samtidig benytter Outlook, Kontorpakke eller andre programmer.

9 16. Kravspecifikationen: 1.6 Bedst mulig markedsføring, markedsføringskanaler og CRM. 1 Ø Musikhuset skal have mulighed for at annoncere via tilbudsgivers platforme. Beskriv mulighederne indeholdt i tilbuddet SPRØGSMÅL: For at sikre sammenlignelighed af de tilbudte ydelser: Kan der fastsættes fælles CPM, kontaktpris, etc? Tilbudsgiver bedes i tilbuddet tydeliggøre, hvad tilbuddet er baseret på, antal mailadresser der udsendes til, åbningsrate o.l Ø Musikhuset skal omtales i tilbudsgivers nyhedsbrev. Beskriv mulighederne indeholdt i tilbuddet. 4 Ø Tilbudsgivers nyhedsbrev skal som minimum kunne segmenteres efter geografi og demografi. Beskriv andre muligheder indeholdt i tilbuddet. 5 Ø Musikhuset skal have adgang til data, der kan tracke onlinekunden fra start til slut i købsprocessen via cookies mm. Beskriv mulighederne indeholdt i tilbuddet. 6 Ø Beskriv udbyders politik og aktiviteter på de sociale medier med henblik på at promovere Musikhus-events og begivenheder. Beskriv mulighederne indeholdt i tilbuddet. Disse ydelser kræver en del særlige kompetencer. Hvorledes ønskes disse kompetencer dokumenteret? Hvorledes ønskes disse ydelser kvantificeret, for at skabe sammenlignelighed - som mandetimer eller kan der skabes en liste over konkrete ydelser? Vi har listet en række områder, som vi har fokus på og ønsker endnu større fokus på i fremtiden. Vi ønsker en beskrivelse af, hvordan I arbejder med nyhedsbreve, segmentering, big data, tracking og sociale medier. Og hvordan I kan hjælpe os til at sælge endnu flere billetter både via jeres egne og vores platforme. Tilbudsgiver bedes udarbejde en liste over konkrete ydelser.

10 28. 9 Ø Tilbudsgiver bedes beskrive andre relevante markedsføringsmuligheder knyttet til deres billetsystem. Tænkes der her på kanaler udenfor Systemets egne? Evt. via partnere? Der tænkes på alle former for markedsføringsmuligheder, der ikke allerede er nævnt i afsnit 1.6. Og det kunne jo fx være via partnere. 29. Kravspecifikationen: Punkt 3. Værdi af evt. øvrige ydelser henviser til ydelser, som Musikhuset ikke har opstillet som ønsker, men som tilbudsgiver kan levere. Der er tale om ydelser der ikke kommer med i den endelige prisevaluering. SPØRGSMÅL : I vejledningen står at ydelser under punkt 3 "ikke kommer med i den endelige prisevaluering". Dette svarer ikke til det der står i udbudsbetingelserne, uddyb gerne hvordan Øvrige Ydelser indgår. Det er korrekt at de tilbudte ydelser ikke indgår i prisevalueringen. DER ER TALE OM EN FEJL. PUNKT 3 I PRISEVALUERINGSSKEMAET SKAL IKKE UDFYLDES. 30. Udbudsbetingelser: Punkt 3. Værdi af evt. øvrige ydelser henviser til ydelser, som Musikhuset ikke har opstillet som ønsker, men som tilbudsgiver kan levere. Der er tale om ydelser der ikke kommer med i den endelige prisevaluering. Det fremgår at øvrige ydelser (punkt 3 i prisbilag) ikke indgår i prisevalueringen. Hvordan vil tilbudte ydelser under dette punkt medtages i evalueringen? Det er korrekt at de tilbudte ydelser ikke indgår i prisevalueringen. DER ER TALE OM EN FEJL. PUNKT 3 I PRISEVALUERINGSSKEMAET SKAL IKKE UDFYLDES 31. Prisskema til bilag C2. Kravsbesvarelse. Pris. Kan MHA bekræfte, at når byder bliver bedt om at angive Gebyr i kr/billet eks. moms i prisskemaet, så er det gebyret som tilbudsgiver modtager pr. solgt billet. Således at dette gebyr minus pris for Ja, det kan bekræftes. Eksempel:

11 den samlede hovedydelse (på hhv. DKK 16 og 4 ekskl. moms), er lig med den gebyrprovision der tilfalder MHA. Tilbudsgiver angiver 5,00 i prisskemaet punkt , hvortil den samlede hovedydelse er 16,00. Andel der tilfalder tilbudsgiver vil i dette eksempel være 5,00 Andel der tilfalder MHA vil i dette eksempel være 11, Licensaftalen: Afregning af billetsalg til Licenstagers event: Licenstager ønsker ikke at modtage løbende afregning af de events, hvor Licenstager er arrangør. I stedet for løbende afregninger, ønsker Licenstager: At endelig afregning skal ske til Licenstager eller Licenstagers samarbejdspartner senest 5 dage, efter eventen har fundet sted. At Licenstager forskudsvis modtager et samlet a conto beløb vedr. forsalget. A contobeløbet reguleres månedsvis i forhold til forsalgets størrelse. Øvrige betalingsbetingelser i overensstemmelse med de til enhver tid værende betalingsbetingelser i Aarhus Kommunes. Såfremt denne struktur påvirker omkostninger hos leverandøren, og dermed tilbuddet, vil det da kunne fraviges, og hvorledes foreslås dette i tilbuddet? Der er ikke tale om grundlæggende vilkår i kontrakten. Såfremt tilbudsgiver ikke kan tilbyde den foreslåede afregningsmetode indenfor det samlede tilbud bedes angives en ekstra pris i prisskemaet under punkt 2. Såfremt tilbudsgiver kan tilbyde en anden model, der er indeholdt i prisen bedes tilbudsgiver endvidere beskrive en alternativ model i bilag B. Tilbudsgivers forbeholdsliste. 33. Bilag C3C - Kvitteringsbilag "Beskrivelse af modtaget materiale:"

12 Det modtagne materiale - er det de data tilbudsgiver modtager fra MHA ved aftaleindgåelse (f.eks. Kundedata)? Eller er det alt materiale der løbende kommer leverandøren i hænde fra MHA og som der løbende skal kvitteres for? Eller er det andet materiale? Er der materiale, der allerede skal kvitteres for ved afgivelsen af tilbuddet og i givet fald hvilket? Ja, det er både materiale, som tilbudsgiver modtager fra Musikhuset ved aftaleindgåelse og det der løbende kommer leverandøren i hænde. Der kvitteres for det hele ifm. aftaleindgåelsen. Såfremt der kommer en ny type data, som ikke er beskrevet i bilaget ved aftaleindgåelse skal der på samme måde laves en aftale for dette. Formålet er, at Musikhuset Aarhus har styr på hvilke data, der er overladt til leverandøren. 34. Bilag C3 - Databehandleraftale 4.2 Ved indgåelse af aftalen vedlægges et bilag D med en oversigt over de tilknyttede medarbejdere, der skal have adgang til Aarhus Kommunes lokaliteter/netværk. Leverandøren er forpligtet til at løbende at tilmelde nye medarbejdere og afmelde medarbejdere, der ikke længere har behov for adgang, til kontraktholder hos Aarhus Kommune." Gælder dette kun medarbejdere, der skal arbejde Dette gælder kun medarbejdere, der skal arbejde direkte på data, der ligger på Aarhus Kommunes direkte på data, der ligger på Aarhus Kommunes netværk eller data, der stilles fortroligt til rådighed netværk og data, der stilles fortroligt til rådighed af af Aarhus Kommune. Eller gælder det også de Aarhus Kommune. medarbejdere, der f.eks. underviser hos MHA på MHAs PC'ere, eller som hjælper med at opsætte printere og programmer hos MHA? Hvis det fremgår af kontrakten, skal der ved underskrift af databehandleraftalen leveres den seneste revisorerklæring, og herunder evt. baggrundsmateriale til erklæringen. Herefter leveres en årlig revisorerklæring, der er udarbejdet i overensstemmelse med de gældende branchestandarder på området (f.eks. ISAE 3000 vedrørende overholdelse af persondataloven). Dette gælder også for evt. underdatabehandlere. Vi er ikke sikre på, om dette fremgår af kontrakten. Kan MHA be- eller afkræfte, om en sådan revisorerklæring skal afleveres ved tilbudsafgivelse eller i forbindelse med indgåelse af kontrakt, efter valg af leverandør? Det fremgår af udbudsbetingelserne 6, at Bilag C3, Databehandleraftalen, bilag C3, B, Krav til databehandleren skal udfyldes og fremsendes til Ordregiver inden kontraktindgåelse, men ikke i forbindelse med indlevering af tilbud. Bilag C3,D, Medarbejderlisten skal udfyldes ved indgåelse af Databehandleraftalen.

13 Databehandleren må kun behandle personoplysninger, som Aarhus Kommune er ansvarlig for, så længe det er nødvendigt for udførelse af den aftalte opgave Ved ophør skal det aftales med Aarhus Kommune, at data skal leveres tilbage til Aarhus Kommune eller der skal ske uoprettelig sletning punkt 3.1. Skal det forstås således, at leverandøren skal slette MHA s data i sit billetsystem, ved ophør af aftalen? Hvad med de tredjemandsarrangementer, som er solgt i tilbudsgivers system, hvor en tredjemand har lejet MHA s faciliteter og ønsker at de data forbliver i leverandørens system? Vi er som virksomhed forpligtet til at opretholde data om økonomiske transaktioner i vores system i min. 5 år. Hvorledes kan det forenes med ønsket om at data slettes efter et evt. ophør af leverandørforholdet? Som udgangspunkt skal data overføres til Musikhuset Aarhus ved ophør af aftalen og slettes fra leverandørens billetsystem. Såfremt leverandøren er forpligtet lovgivningsmæssigt til at opretholde data om økonomiske transaktioner i op til 5 år, laves der en særlig aftale om dette forhold i kontrakten, således at det sikres, at disse data udelukkende anvendes til at opretholde data om økonomiske transaktioner og således at det sikres, at disse data slettes efter 5 år. 37. Bilag C -licensaftale 12.2 Licenstager betaler ikke gebyr ved følgende: Print af arrangørbilletter Salg af gavekort Tilbagekøb af billetter P-billetter og andre artikler i webshop, der ikke vedrører billetter Ad. Pkt 1: Kan MHA definere hvad en "arrangørbillet" er? Ad. Pkt 4: Den fulde webshop, samt løbende afregning af denne, skal stilles frit til rådighed, uanset om MHA sælger 5000 varer pr. år eller varer? Og det skal gælde alt der sælges igennem tilbudsgivers systemer, der ikke er en billet? En arrangørbillet er en billet, der har status af fribillet i billetsystemet, selvom prisen fremgår af billetten. Ca. 100 i Ja, det er korrekt. I 2014 solgte vi varer via produktmodulet i nuværende billetsystem til en værdi af kr Heraf var de varer solgt online værdi kr Licenstager skal stille følgende til rådighed for Leverandøren: a) -forbindelse til SMS-port, herunder vedligeholdelse og information vedrørende adgangsdata og tekniske specifikationer;

14 Kan MHA uddybe, hvad der menes med " forbindelse til SMS-port"? Leverandøren skal stille en SMS-gateway til rådighed for Musikhuset i Aarhus. Hvordan billetsystemet kommunikere med SMS-gateway er Musikhuset uvedkommende. Leverandøren skal altså stille både billetsystem og SMS-gateway til rådighed i sit løsningsdesign Ø Onlinekunden skal have mulighed for at betale i rater samt på kredit. Administration samt risiko ligger hos tilbudsgiver. Kan MHA uddybe forskellen på rate og kredit. Skal det forstås således, at kunden skal kunne købe billetter helt uden initial betaling? Hvis et meget stort antal kunder vælger en af ovenstående former for betaling, vil tabsrisikoen kunne blive betragtelig for tilbudsgiver. Accepterer MHA at tilbudsgiver dækker sin risiko af, gennem yderligere gebyrer fra kunden? Hvis en kunde ikke kan betale sine rater eller kredit og dermed ikke har opfyldt sin betalingsforpligtelse. Skal kunden så stadig kunne benytte sin billet? Forventer MHA stadig at indeholde fuld betaling for billetten fra leverandøren og forventes der udbetaling af hele billetten pris ved købet til MHA, eller i takt med at raterne indløber? Der burde have stået rate ELLER kredit. Det er tilbudsgiver, der fastlægger de nærmere betingelser i tilbuddet. MHA kan godt acceptere, at tilbudsgiver dækker sin risiko af gennem gebyr eller rentebetaling. Dette bedes beskrevet nærmere i tilbuddet. Det er tilbudsgiver, der har risikoen og afgør, om kunden skal kunne benytte sin billet. Musikhuset Aarhus forventer at få fuld betaling fra tilbudsgiver ifm købet. 40. Vedrørende dokumenterne i udbuddet. Kan MHA bekræfte eller korrigere følgende?: Dokumenter der skal være udfyldt ved indlevering af tilbud: Bilag A. Tilbudsblanket JA Bilag B Tilbudsgivers forbeholdsliste JA Bilag C til databehandleraftale NEJ, skal først underskrives umiddelbart før underskrivelse af licensaftale Bilag C1. Kravspecifikation NEJ, den skal ikke udfyldes

15 Bilag C2. Løsningsbeskrivelse JA BILAG C2 Prisbilag JA, men punkt 3 i prisbilaget skal ikke udfyldes Bilag C3 Databehandleraftale NEJ, skal først underskrives umiddelbart før underskrivelse af licensaftale Bilag C3B navn-efternavn-firma NEJ, skal først underskrives umiddelbart før underskrivelse af licensaftale Dokumenter der først skal udfyldes ved indgåelse af aftale, efter valg af leverandør: Bilag A - IT-sikkerhedspolitik (reference) JA, bilag C3A skal først underskrives umiddelbart før underskrivelse af licensaftale Bilag C Licensaftale JA BILAG C4 Tidsplan for implementering JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelse af licensaftale BILAG C5 Tidsplan for implementering af de yderlser, der ikk.. JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelsen af licensaftale BILAG C6 Licenstagers medvirken JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelse af licensaftale BILAG 7 Aarhus Kommunes IT miljø Accepteres ifm underskrivning af licensaftalen BILAG 8 Samarbejdsorganisation JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelse af licensaftale BILAG 9 Oppetider JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelse af licensaftale BILAG C10 Priser JA, udfyldes i overensstemmelse med revideret tilbud umiddelbart før underskrivelse af licensaftale BILAG C11 Anfordringsgaranti JA, udarbejdes umiddelbart før underskrivelse af licensaftale Bilag D til databehandleraftale JA, bilag C3D JA, udfyldes umiddelbart før underskrivelse af licensaftale