Spørsmål og svar nr. 3.

Transkript

1 Spørsmål og svar nr. 3. Konkurranse Kontaktinformasjon NT , Kjøp av Mobilkommunikasjon med Gateway tjenester Frist for å stille spørsmål Dato / kl Dokument sendt Dato Generelt Denne anskaffelsen er underlagt Lov og forskrift om offentlige anskaffelser og Norsk Tipping anser det derfor særdeles viktig at alle leverandører behandles likt, også i forhold til informasjon. 1.2 Formål Formålet med dette dokumentet er å gi svar på innkomne spørsmål vedrørende konkurransen nevnt over. 1.3 Spørsmål vedrørende konkurransen Alle henvendelser skal gjøres skriftlig til e-postadressen over. Ethvert forsøk fra leverandørene på å skaffe seg informasjon vedrørende denne anskaffelsen via andre kanaler enn e-postadressen over kan medføre avvisning fra konkurransen.

2 2. Spørsmål og svar R011 Med "logg over brukeraktivitet", menes det at man skal kunne se en historikk over hvilke sider en bruker innlogget på administrasjonsweben har gjort? Eller menes det logg/historikk over meldinger til og fra et mobilnummer? Det menes logg/historikk over meldinger til og fra et mobilnummer R012 Med dette kravet, mener dere at det skal legges begrensninger på hvilken type tjenester som er mulig å knytte til et kortnummer, og at ansatte i NT skal kunne endre disse begrensningene? Eller mener dere at det skal være mulig å beskrive de ulike kortnumrenes formål, til hjelp for NTs ansatte når de skal administrere tjenester? Og, gjelder disse begrensningene bare ved manuelle utsendelser fra administrasjonsverktøy, eller også ved utsendelser sendt direkte via SMS Gateway. Kan dere komme med noen eksempler på hva dere mener med type meldinger? R013 Med sperring og gjenåpning av abonnement, tenker dere på mobilabonnement hos mobiloperatører, eller kundeforhold hos NT? Det vi mener er at vi benytter oss av flere kortnummer for ulike tjenester. Det må vi fortsatt kunne i en overgangsperiode, selv om vi har som mål å benytte et nummer på sikt. Spørsmålet er da hvordan leverandøren løser dette for Norsk Tipping. Mobilabonnement hos mobiloperatører Norsk Tipping AS, 2013 Side 2/13

3 R014 Angående API for å motta meldinger om sperrede nummer. Har dere allerede et API for å ta i mot slike meldinger, eller kan dere tilpasse dere? Ønskes det er callback per melding, eller en samlet oppstilling i et API-kall? Kan dere beskrive hvordan dataene passer inn i deres arbeidsflyt? R22 Gitt at det er spesifisert et tidsrom der det skal tillates å sende meldinger. Hvis et forsøk på å sende da kommer inn 21.05, ønskes det at kallet avvises med en feilmelding, eller ønskes det at meldingen legges i kø for utsending klokken neste dag? Gjelder denne sperren kun for utsendelser initiert fra administrasjonsverktøyet, eller også for utsendelser sendt direkte via SMS Gateway? Hovedpoenget med dette kravet, er at vi skal få tilbakemelding fra Gateway om/at et nummer vi prøver å sende melding til er sperret på en eller annen måte. Vi har i dag en integrasjonsløsning som kan tilpasses til API-er en leverandør kan tilby. Informasjon om sperring kan skje ved direkte respons fra GW når vi sender melding til GW, eller i ettertid (vha callback når meldingen er «mottatt»). Hvorvidt dette gjøres per melding (enkeltvis) eller samlet i «batch» er litt opp til bruksmønsteret, men vi ser for oss at mulighet for begge deler er en fordel. Overordnet er det (per nå) to «arbeidsflyter» rundt utsendelse av SMS; Enkeltvis (personlig) melding sendt til kunde(r) (typisk trigget av hendelser) Masseutsendelse (bulk) til en mengde kunder (typisk med likt markedsføringsbudskap) basert på et uttrekk av kunder fra vår kundedatabase. Det kommer an på type utsendelse det handler om. Visse utsendelser skal ikke sendes neste dag da budskapet er uaktuelt og utdatert, men andre skal sendes ut dagen etter. Leverandøren skal beskrive hvordan disse situasjonen løses Norsk Tipping AS, 2013 Side 3/13

4 R034 Kan dere beskrive en normal testflyt fra deres side? Hvilke parametre trenger dere å administrere i forbindelse med testing, gjelder dette for eksempel oppsett av URL for endepunkter som skal håndtere leveringskvitteringer og innkommende meldinger? Skal det bare være simulering av sending av meldinger, eller skal også mobiloriginerte meldinger og leveringskvitteringer simuleres? Skal det bare være simulering av sending av meldinger, eller skal også mobiloriginerte meldinger og leveringskvitteringer simuleres? Ja, vi ønsker mulighet for å simulere alle alternative oppgitt ovenfor. URL må kunne endres, telefonnummer i meldingene må kunne erstattes med alternativt nummer før utsending. F.eks ved at vi setter erstatningsnr ett sted og alle meldinger som da kommer etterpå går ut på det angitte nr. Når nr fjernes, går melding ut til opprinnelig mottaker. Vi ønsker at leverandør kommer med et forslag til hvordan vi tester baserte på leverandørens løsning. Testcases : Fra kunde NT kunde, og NT Kunde R035 Med dette kravet, mener dere at det skal være mulig å sende meldinger fra testmiljøet til reelle mobiler, eller mener dere at vanlige sendemetoder skal simulere den feedbacken man vanligvis får fra systemet? Gjelder testmiljøet kun for SMS Gateway, eller menes det også fra administrasjonsverktøyet? Vanlige sendemetoder skal simulere den feedbacken man vanligvis får fra systemet. Vi ønsker at leverandør skisserer hvilke muligheter som leverandørens løsning leverer. Sms gateway må være tilgjengelig i testmiljøet, admin verktøy må være tilgjengelig dersom vi benytter tjenester hos leverandør som administreres via admin verktøyet. R036 Hva mener dere med testbrukere til administrasjonsverktøyet? Mener dere brukere til et separat testmiljø, eller mener dere en alternativ type brukere til produksjonsversjonen av programvaren? Vi må kunne gjøre det samme i test som i produksjon, og vi ønsker at leverandøren beskriver hvordan dette kan gjennomføres. Norsk Tipping AS, 2013 Side 4/13

5 R037 Mener dere med dette en predefinert liste med fiktive norske telefonnummer? Eller mener dere en nummerserie? Hvor mange fiktive nummer ønsker dere tilgjengelig? Gjelder dette både utsendelser initiert fra administrasjonsverktøy eller også utsendelser sendt direkte via SMS Gateway? R038 Kan dere utdype eller komme med et eksempel på hva dere legger i dette kravet? Gjelder det mulighet for å motta meldinger fra telefoner i forbindelse med testing, eller mulighet for å teste utsendelser, men der selve utsendelsen stoppes? Kan dere komme med en beskrivelse eller et eksempel på et testscenarier dere ønsker å få testet, i henhold til punkt R038? Vi må kunne oppgi et sett med telefon nummer som skal kunne være deltakere i en test, slik at bare disse vil motta meldinger i et testløp Norsk Tipping har mange tjenester som henter grunnlagsdata fra spillsystemene, og for å teste disse, må vi noen ganger ta data fra produksjonssystemene og bruke i testene. Disse kan inneholde opplysninger som f.eks. telefonnr, og denne opplysningen må erstattes før melding går ut fra SMS gateway, for å hindre at sluttbruker blir en del av testen. Denne type tester må benytte muligheter ref. krav R034. Norsk Tipping AS, 2013 Side 5/13

6 R043 Gjelder kravene dere stiller til passordsikkerhet også passord for autentisering inn mot SMS Gateway API i R031 eller gjelder det kun for innlogging via webgrensesnitt? For eksempel er det mot API ikke anbefalt at et passord skal kunne "resettes" av kunde hvis det er glemt. Da kan det hende at Gateway trafikk fra noen klienter stopper opp siden Leverandør ikke har kontroll med hvilken passord Kunde har satt opp for aktuell klient. Vi antar også at to-faktor autentisering ikke er et krav for API tilgang. Stemmer dette? For tilgang til API gjelder ikke kravet om to-faktor autentisering. Resett av passord inn mot API er er heller ikke noe krav men vi vil heller ha leverandørens anbefalinger, / rutiner for å skifte passord/ sikre riktig tilgang til disse. R047 Gjelder det for gateway, eller kun for webbasert applikasjon? I dag benytter vi oss av tjenesten NTSTOPP til 2030 for kunder som ikke ønsker å motta budskap. Vi har ikke hatt en automatisk oppdatering mot Norsk Tipping sitt kunderegister selv om det har vært ambisjonen. Norsk Tipping trenger en beskrivelse på hvordan leverandøren holder oversikt over disse kundene, og påse at de ikke mottar noe i fra Norsk Tipping så lenge de ligger i sperrelisten. Norsk Tipping AS, 2013 Side 6/13

7 R50 Med "Dette (meldinger sendt til NT) må også kunne sendes som API direkte til våre system", menes det at det skal være mulighet for å polle etter en historikkfil, eller mener dere vanlig SMS Gateway funksjonalitet for forwarding av mobiloriginerte meldinger og leveringskvitteringer? Med "Meldinger sendt til NT", mener dere da innkommende meldinger til NTs kortnummer, eller meldinger som blir videresendt til NTs systemer via API? Hensikten med kravet er at vi trenger informasjon på kunder som sender saker til Norsk Tipping sitt kortnummer. Norsk Tipping skal ha en direkteoppdatering av disse tilfellene av det vi trenger. For eksempel: En kunde sender NTSTOPP til Da trenger vi ha informasjon for å kunne oppdatere kunden i Norsk Tipping sitt system via Leverandørens API. R055 Kreves det fletting av lister ved sending av SMS via SMS Gateway, eller er dette kravet begrenset til sending fra web-basert verktøy? Dette behovet er for begge typer utsendelser, så vi trenger å vite hvordan dette løses begge veier. Kortnummeret 2030 er så hvit vi er bekjent eid av Eurobate og brukes av andre kunder av dem som f.eks. RiksTV. Hvordan skal leverandør med unntak av Eurobate kunne hoste dette nummeret, eventuelt er det en feil at leverandør skal hoste det? 2030 er tydeligvis et «delt kortnummer», og ved bytte av gateway leverandør må vi da bruke et annet nummer. Tidligere besvarte spørsmål Norsk Tipping AS, 2013 Side 7/13

8 1 Besvart tidliger e R025: I krav R025 krever dere støtte for audit og kapasitetsanalyse. Hva legger dere i behovet for kapasitetsanalyse? Kan dere utdype? Hvilken kapasitet ønsker dere å analysere? For at Norsk Tipping skal få en god tjeneste er det viktig at leverandøren overvåker og gjør analyser av sin ytelse for tjenesten som skal leveres. Norsk Tipping ønsker med dette spørsmålet at leverandøren gir en beskrivelse av hva de gjør for å sikre leveransen av tjenesten, herunder analyse av kapasitet. Det er opptil leverandøren å beskrive sine rutiner innenfor området. 2 Besvart tidliger e R032: I krav R032 krever dere integrasjon mot andre systemer, eksemplifisert med Siebel Marketing. Kan dere dele informasjon om hvilke grensesnitt Siebel Marketing tilbyr, samt dokumentasjon av disse? Eksisterende integrasjon mot SMS Gateway går via vår integrasjonsplattform, der sender Siebel Marketing meldinger i XML-format over MQ som plukkes opp av en tjeneste på integrasjonsplattformen som så sender til SMS Gateway via en http-tjeneste som SMS Gateway tilbyr. Mulighetene med integrasjon mot Siebel Marketing: - Eksport/import fra fil - Eksport/import via meldingskø som MQ - http-tjeneste ut/inn - Web service ut/inn - SMTP («SMS som e-post») Siebel Marketing hos NT kjører på Oracle Siebel CRM Generell dokumentasjon finnes her: Og spesifikt om integrasjon: Norsk Tipping AS, 2013 Side 8/13

9 3 Besvart tidliger e R038: I krav R038 krever dere at det skal være mulig å stoppe/holde tilbake meldinger i forbindelse med testing. Kan dere utdype hva dere mener med dette? Med det så menes at vi f.eks velger å teste utgått kupong tjenesten vår, og at vi da har data vi har speilet fra produksjon for å få inn relevante data å utføre testen på. I datagrunnlaget finner vi da mange utgåtte kuponger, og ønsker da å kunne simulere en utsending til disse, men stoppe meldingene fra å nå fram til kunden siden dette et ment for testing. Får vi ikke stoppet de vil vi risikere å støye ned kunden med meldinger de ikke har bedt om å få, og til tidspunkter som kanskje ikke matcher når meldingene normalt hadde blitt sendt ut. I dag løser vi dette ved å «tukle» med datagrunnlaget, ved f.eks å bytte ut kundens telefonnummer med andre nummer. Dette er ikke godt nok, da telefonnummer er nøkkel ID i mye av SMS tjenestene. Derfor er det et krav om at dette må løses på en annen måtet - «skarpe» tester med reelle data, og stoppe utsendelsene på gateway når vi ikke vil at kundene skal se at vi driver med testing. 4 Besvart tidliger e R047: I Krav R047 krever dere at løsningen ikke skal sende SMS til kunder som ikke har samtykket i å motta SMS. På hvilken måte får dere samtykke fra kunder i dag? Kan samtykke innhentes via SMS? Alle samtykker kommer inn ved registrering av nye kunder gjenom at kunden selv velger å samtykke hos kommisjonær eller på internett/mobil. Kunden kan endre sitt samtykke ved å ringe kundeservice eller å endre sine data selv på internett eller mobil. I dag har vi ingen automatisk avregistrering av kunder som sender inn at de ikke vil ha flere SMS fra oss ved å sende NTSTOPP till Vi trenger derfor at leverandøren av SMS-tjenster kan vaske bort kundene som har sendt NTSTOPP til 2030 fra framtidige utsendelser, inntil vi får på plass en automatisk løsning. Norsk Tipping AS, 2013 Side 9/13

10 5 Besvart tidliger e Må det leveres MMS tjeneste Svaret er «ja». R017 er et ufraviklig krav «U». Det er dessverre en «K» i konkurransedokumentene Krav id R025: Kan dere utdype hva dere mener med støtte for audit og kapasitetsanalyse som er et ukjent begrep for oss For at Norsk Tipping skal få en god tjeneste over tid er det viktig at leverandøren overvåker og gjør analyser av sin ytelse for tjenesten som skal leveres. Norsk Tipping ønsker at leverandøren gir en beskrivelse av hva denne gjør for å sikre leveransen av tjenesten, herunder analyse av kapasitet Krav id R028: Hva legger dere i ordet endringshåndtering I ordet «endringshåndtering» legger vi hvordan leverandøren håndterer endringer (endringsprosess). Norsk Tipping ønsker at leverandøren beskriver hvordan endringer håndteres på et overordnet nivå for, gjerne med eksempler. Norsk Tipping AS, 2013 Side 10/13

11 Bilag 07 - Prismatrise Gateway * Hva er mest ønskelig for Norsk Tipping. En fordeling på operatør basert på meldinger fra Link Mobility sine Gatewayer (totalt ca 120 millioner SMS i 2013) eller siste rapport fra Post og Teletilsynet hvor også operatører som ikke vil være aktuelle grunnet at de ikke eier linjene står oppført. For eksempel Lyca Mobile som står oppført med 2,9% markedsandel, men som ikke vil være med dersom våre priser skulle danne grunnlaget * Operatører i Norge priser etter 3 ulike måter: Cpa0, Cpa (overtakserte meldinger) og bulk. Overtaksert er håndtert under punkt 8. Skal også Cpa0 være med under punkt 1? * Punkt 6 og 9: Hvor i prismatrisen ønsker dere kostnaden for driften av kortnummer 2020 og 2030? Bilag 07: Hvis CPA0 betyr CPA meldinger til tariff 0 kr bør det være med under punkt 1(R065), men om priser skiller seg i fra bulk sms så må det framgå av priser for både cpa0 og bulk. Vi vil anta at det bør være Post og Teletilsynets liste som bør være gjeldende for alle, og ikke den enkelte operatørs interne lister som benyttes. Drift av kortnummer 2030 og 2020 bør inngå i punkt 6. For Norsk Tipping går det bra om de legger det inn i punkt 9 i stedet, så lenge prisene er uttømmende. Norsk Tipping AS, 2013 Side 11/13

12 R038: Norsk Tipping krever at leverandøren skal beskrive mulighet for å motta meldinger som holdes tilbake/stoppes i forbindelse med testing. Kan dere klargjøre for oss hva dere er ute etter her, vi har litt problemer med å forstå hva dere er på jakt etter i kravet. Vi ønsker å kunne gjennomføre testing så helhetlig som mulig (dvs også mot et SMS-gateway), men på en slik måte at meldingene ikke sendes ut til kunde men holdes tilbake / stoppes slik at vi kan se hvilke meldinger som ville blitt sendt om trafikken hadde vært routet til produksjonssystemet. Ved testing av SMS tjenester medfører for noen tjenester vi tilbyr, at vi må hente ut data fra produksjonssystemene for å kunne foreta testene. Istedenfor å kjøre full integrasjontest A-Å, må disse testene kunne stoppes før melding når ut til sluttmottaker, da vi ikke ønsker å eksponere testdata til kunder, og ønsker heller ikke kostnad med SMS utsendinger knyttet til denne type testing. Som eksempel kan nevnes prosessen med å sende ut personlig premievarsling til vinnere. Her bruker testen real time data fra spillsystemene til å generere grunnlag for hvem som skal ha meldinger om premie, men selve utsendelsen av varslingssms ønsker vi ikke å sende ut til sluttbruker ifm. testing. Vi ønsker bare å teste prosessen fra der den starter og fram til melding har kommet fram til leverandørs SMS gateway. Vi ønsker å ha med test trinn fram til overlevering av melding på gateway for å sikre at hele verdikjeden innenfor Norsk Tippings infrastruktur er ok. Teknikker for å holde tilbake meldingene hos SMS leverandøren kan da være f.eks at meldingene sendes til en annen webadresse enn for produksjonsmeldinger når vi skal teste, eller at innholdstekst i melding har en form som gjør at det kan leses av at dette er testmeldinger som ikke skal sendes videre, men stoppes i gateway. Her er det opp til leverandør å komme med forslag til et bra oppsett på hvordan et testmiljø kan settes opp og administreres. Norsk Tipping AS, 2013 Side 12/13

13 Knyttet til R032 er vi usikre på om Leverandøren skal gjøre en integrasjon direkte mot Siebel Marketing eller om dette skal fortsatt gjøres via Norsk Tipping sin integrasjonsplattform slik at Leverandør ikke forholder seg direkte til Siebel Marketing. Jobben med integrasjonen blir da i så fall tilpasningen mellom Norsk Tipping sin integrasjonsplattform og leverandøren sin SMS Gateway? Utsending skal skje via tjenestelaget. Dermed blir integrasjonen mellom SMS Gateway og integrasjonsplattformen Knyttet til R041 er det et krav om at «løsningen sikres slik at ingen tjenester er tilgjengelig for eksterne». Kan dere utdype dette? Dette har med sikkerhet å gjøre og sikring av at tjenestene ikke er tilgjengelig for uvedkommende. Sikre tilgangen slik at ikke eksterne kan komme inn på admin delen av løsningen. Norsk Tipping AS, 2013 Side 13/13