Anskaffelse av skybasert billett- og adgangssystem (SaaS) for Moldebadet

Anskaffelse av skybasert billett- og adgangssystem (SaaS) for Moldebadet. Kontrakten reguleres av SSA L (vedlagt) og inkluderer krav til funksjonalitet, integrasjoner, implementering, drift/support, SLA og informasjonssikkerhet/personvern. Det kan ikke gis deltilbud. Leveranse er planlagt til september/oktober. (Kilde: pkt. 1 GENERELL BESKRIVELSE)

• Leverandøren skal være registrert i et foretaksregister, faglig register eller registrert i handelsregister i den staten leverandøren er etablert.

  Dokumentasjon: Norske selskaper: Firmaattest. Utenlandske selskaper: Godtgjørelse på registrering i tilsvarende register. (Kilde: pkt. 3.1)

  Kilde: pkt. 3.1 Leverandørens registrering, autorisasjon mv.
• Norske leverandører skal ha ordnede forhold til betaling av skatt og offentlige avgifter.

  Dokumentasjon: Skatteattest (ikke eldre enn 6 måneder regnet fra fristen for å levere tilbud). Gjelder bare norske leverandører. (Kilde: pkt. 3.1 og pkt. 2.1)

  Kilde: pkt. 3.1 Leverandørens registrering, autorisasjon mv. / pkt. 2.1 Skatteattest
• Valgte leverandør skal på forespørsel levere skatteattest for merverdiavgift og for skatt (gjelder bare dersom valgte leverandør er norsk), ikke eldre enn 6 måneder fra fristen for å levere forespørsel/tilbud om å delta.

  Dokumentasjon: Skatteattest for merverdiavgift og skatteattest for skatt. (Kilde: pkt. 2.1)

  Kilde: pkt. 2.1 Skatteattest
• Leverandøren skal ha erfaring fra sammenlignbare oppdrag.

  Dokumentasjon: Beskrivelse av inntil 3 mest relevante oppdrag de siste 3 årene, med verdi, tidspunkt og mottaker (navn, telefon og e-post). Leverandøren må dokumentere relevans. Erfaring kan dokumenteres ved kompetanse til personell leverandøren råder over (selv om erfaringen er opparbeidet hos annen leverandør). (Kilde: pkt. 3.2)

  Kilde: pkt. 3.2 Leverandørens tekniske og faglige kvalifikasjoner
• Leverandøren skal ha et kvalitetssikringssystem tilpasset leveransens kompleksitet og risiko, sertifisert i henhold til ISO 9001 eller tilsvarende.

  Dokumentasjon: Kopi av gyldig sertifikat (tilfredsstilles ved å legge ved kopi av gyldig sertifikat). (Kilde: pkt. 3.2)

  Kilde: pkt. 3.2 Leverandørens tekniske og faglige kvalifikasjoner
• Leverandøren skal arbeide systematisk med helse, miljø og sikkerhet.

  Dokumentasjon: Signert etikk-egenerklæring. (Kilde: pkt. 3.2)

  Kilde: pkt. 3.2 Leverandørens tekniske og faglige kvalifikasjoner
• Leverandøren skal ha system for sporbarhet i leverandørkjeden og retningslinjer for sosialt ansvarlig produksjon.

  Dokumentasjon: Utfylt og signert HMS-egenerklæring. (Kilde: pkt. 3.2)

  Kilde: pkt. 3.2 Leverandørens tekniske og faglige kvalifikasjoner

• Tilbudet skal leveres i sin helhet etter den utformingen det elektroniske systemet (KGV) for innlevering angir, innen tilbudsfristen.Kilde: pkt. 5.1 Tilbudets utforming
• Anbefalt: benytte elektronisk signatur for å autentisere ved innlevering av tilbud.Kilde: pkt. 5.2 Elektronisk signatur
• Vinneren skal i tillegg levere skatteattest.Kilde: pkt. 5.1 Tilbudets utforming
• Leverandøren skal svare på kundens kravspesifikasjon (Bilag 1 i SSA-L) og besvare under kvalitetstildelingskriteriet.Kilde: pkt. 4 Tildelingskriterier (Kvalitet / SSA-L Bilag 1)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

17.06.2026

Språk

norsk

Elektronisk katalog

Tillatt

• Kontrakten reguleres av SSA L (vedlagt).Kilde: pkt. 1.3 Kontraktsvilkår
• Plan for implementering: leverandør skal i tilbudet legge ved plan fra kontraktsignering til implementeringen er ferdigstilt, inkl. oversikt over antall uker til systemet tidligst kan være i drift, milepæler, varighet, opplæring, og ansvars-/ressursforventninger.Kilde: Bilag 1 SSA-L / pkt. 7.1 Implementering, migrering og opplæring
• Testregime og godkjenningskriterier samt ansvarsmatrise og estimat på nødvendige ressurser hos kunden.Kilde: Bilag 1 SSA-L / pkt. 7.2, 7.3 og 7.4
• Plan for opplæring/kurs, inkludert opplæring ved etablering, løpende opplæring, opplæring ved versjonsoppdateringer og tilgang til brukerveiledning/hjelpefunksjoner i systemet.Kilde: Bilag 1 SSA-L / pkt. 7.5 Opplæring og dokumentasjon
• Supportkrav: support på norsk på telefon (ikke chatbot), hverdager 08:00–16:00. (Ut over dette evalueres under SLA.)Kilde: Bilag 1 SSA-L / pkt. 8.1 Drift, support og tjenestenivå (SLA)
• Beredskaps- og kontinuitetsplaner for tilgjengelighet i henhold til SLA.Kilde: Bilag 1 SSA-L / pkt. 8.2
• Rutiner for endringshåndtering (nye versjoner/oppdateringer/patcher) beskrevet i bilag 4.Kilde: Bilag 1 SSA-L / pkt. 8.3
• Supportløsning og versjonsoppgraderinger i «systemets levetid» skal være inkludert: retting/tilpasninger, vedlikehold, statusmøter, brukerforum, fremtidige versjoner.Kilde: Bilag 1 SSA-L / pkt. 8.4
• SLA skal beskrives i bilag 4 og minimum inneholde bl.a. brukerstøtte, programvarerettelser/vedlikehold og nye versjoner, sikkerhetskopiering/gjenoppretting/beredskap, oppetid/nedetid (minstekrav), feilmeldingsprosedyre (responstid/rapportering), eskaleringsrutiner, prisavslag/kompensasjoner og varsling av nedetid.Kilde: Bilag 1 SSA-L / pkt. 8.5
• Krav til informasjonssikkerhet: ISMS basert på GDPR og ISO 27001 (eller tilsvarende), minimum dekke ansvarsstruktur, dokumenterte tiltak, sikkerhetsmål/strategi, årlig ledelsens gjennomgang, og avviksoppfølging.Kilde: Bilag 1 SSA-L / pkt. 9.1
• Databehandleravtale: databehandleravtalen som skal signeres i forbindelse med avtaleinngåelse skal være ROR-IKTs databehandleravtale (Digdir standardmal).Kilde: Bilag 1 SSA-L / pkt. 9.2
• GDPR-krav inkl. innebygget personvern: innebygget personvern, personvern som standard, dataminimering og registrertes rettigheter.Kilde: Bilag 1 SSA-L / pkt. 9.3
• Endringshåndteringsprosess som varsler kommunen ved endringer/vedlikehold som krever nedetid; samt prosess for kapasitetsstyring for tilgjengelighet.Kilde: Bilag 1 SSA-L / pkt. 9.4 og 9.5
• Logging av autoriserte/uautoriserte tilgangsforsøk og relevante sikkerhetshendelser samt krav til sikkerhetslogger og systemlogger.Kilde: Bilag 1 SSA-L / pkt. 9.6
• Sikkerhetskopier: verifisere innhold i sikkerhetskopier og teste gjenoppretting; sikre at sikkerhetskopier ikke kan kompromitteres; samtidig sikkerhetskopiering mens løsningen er operativ; sikkerhetstesting ved oppdateringer/planlagte/uplanlagte endringer; adskilt testmiljø fra produksjon; sikkerhetsarkitektur iht. NSM grunnprinsipper.Kilde: Bilag 1 SSA-L / pkt. 9.7–9.12
• Etableringsfase: fremlegge konfigurasjonskart som viser dataflyt i løsningen.Kilde: Bilag 1 SSA-L / pkt. 9.13
• Logging av aksessering av data for sluttbrukere og admin: hvem/hva/når og endringslogg; kun Administrator skal ha lesetilgang til endringslogger, og logger må være søkbare.Kilde: Bilag 1 SSA-L / pkt. 9.14
• Integrasjoner/APIs: støtte for KS Fiks Arkiv API mot kommunens arkiv; API for gjenbruk av data (f.eks. Power BI); støtte REST og SOAP; API-autentisering/autorisasjon (OAuth2/WS-Security), TLS-kryptering, og feilhåndtering (HTTP statuskoder/meningsfulle feilmeldinger).Kilde: Bilag 1 SSA-L / pkt. 5.1–5.6

• Dokumentteksten viser ikke konkrete verdier for tildelingsvekter; «prioritert rekkefølge» er angitt, men uten tallvekting.
• Etablerings-/leveransedatoer etter tilbudsfrist er «foreløpige» og kan justeres; eksakte datoer er ikke fastsatt i teksten.
• Flere kvalifikasjonskrav i pkt. 3.2 er formulert noe generelt (f.eks. «signert etikk-egenerklæring» og «HMS-egenerklæring») uten at det fremgår hvilke konkrete vedlegg/dokumentnavn som skal brukes i selve konkurransegrunnlaget (kun at vedlegg finnes).
• Tjenestenivå/SLA inneholder et minstekrav for oppetid («minium <xx,xx%>») som ikke er utfylt i den viste teksten.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I Bilag 1 pkt. 8.5 står at oppetid/nedetid skal måles over 1 år og at minium kravet er «<xx,xx%>», men tallverdien ser ut til å være en mal/placeholder. Kan oppdragsgiver bekrefte hva som er faktisk minstekrav til oppetid (i prosent) og hvordan nedetid skal avgrenses/medregnes (planlagt/ikke-planlagt, vedlikeholdsvinduer, hendelser) ?

   Hvorfor det er verdt å spørre: Leverandøren må vite eksakt minstekrav og beregningsgrunnlag for å prise og dimensjonere drift og SLA-oppfyllelse korrekt, og for å kunne levere et SLA-bilag uten risiko for avvik.

   Kilde: Bilag 1 pkt. 8.5 (SLA) / «Tjenestenivå med standardiserte kompensasjoner» (Bilag 4)

2. Bilag 1 pkt. 8.5 ber om beskrivelse av responstid, feilmeldingsprosedyre og eskaleringsrutiner, og at dette skal beskrives i bilag 4. Kan oppdragsgiver oversende/konkretisere hvilke konkrete responstidsnivåer (f.eks. P1/P2/P3 og tid til oppstart) som skal legges til grunn for minimumskrav og evaluering, eller angi om disse nivåene er helt frie for leverandøren å foreslå?

   Hvorfor det er verdt å spørre: Utydelig krav til responstid og kategorisering (P-nivåer) gjør det vanskelig å estimere kostnad og levere sammenlignbar SLA i tilbudet.

   Kilde: Bilag 1 pkt. 8.5 (SLA)

3. Tildelingskriteriene i del I (pkt. 4) beskriver at tildeling skjer basert på beste forhold mellom kvalitet og pris/kostnad, men dokumentutdraget viser ikke vektfordeling/underkriterievekt. Kan oppdragsgiver bekrefte vektfordelingen mellom «Kvalitet» og «Pris» (og eventuelle undervekter innen kvalitet), eller opplyse om at vekt ikke brukes (ren prioritet som beskrevet)?

   Hvorfor det er verdt å spørre: Uten vektfordeling kan leverandøren ikke allokere innsats riktig mellom bilag 1/kravbesvarelser og pris, og risikerer å misforstå evalueringen.

   Kilde: Konkurransegrunnlag del I pkt. 4 (Tildelingskriterier)

4. I Bilag 1 pkt. 5.1 vises det til KS Fiks Arkiv API, og det står: «Dersom GI-arkiv tjenestegrensesnittet er benyttet skal leverandør beskrive utviklingsplan for støtte av KS FIKS Arkiv. Det forutsettes at en ev. utvikling av støtte for KS Fiks ikke skal medføre kostander for Kunden.» Kan oppdragsgiver spesifisere om Molde kommune i dag benytter GI-arkiv og/eller om KS FIKS allerede er i bruk, og hvilke konkrete integrasjonsendringer som forventes (inkl. forventet omfang og tidshorisont)?

   Hvorfor det er verdt å spørre: Kravet om at utvikling for KS Fiks ikke skal koste kunden kan innebære betydelig utviklings-/leveranserisiko. Leverandøren trenger faktisk utgangspunkt og forventet omfang for å prise og styre leveransen.

   Kilde: Bilag 1 pkt. 5.1 (KS Fiks Arkiv / utviklingsplan)

5. Bilag 1 pkt. 5.7 krever «API mot Visma Enterprise for faktura og økonomi», men uten ytterligere spesifikasjon i utdraget. Kan oppdragsgiver opplyse hvilken integrasjonsmetode som skal benyttes (API/fil/annet), hvilken versjon/produkt (Visma Enterprise) og eventuelle endpoint-krav, samt hvilke data som skal utveksles (retur/feiltilstander), og om det finnes dokumentasjon/tekniske krav vedlagt i konkurransen (f.eks. i excel/bilag)?

   Hvorfor det er verdt å spørre: Integrasjon mot økonomisystemet er ofte den største tekniske kostnadsdriveren. Leverandøren må få nok detaljer til å estimere utvikling, testing og løpende drift.

   Kilde: Bilag 1 pkt. 5.7 (API mot Visma Enterprise for faktura og økonomi)

6. Bilag 1 pkt. 2.1.5.1 beskriver kapasitetshåndtering i realtid og at dette skal vises på Molde kommune sine hjemmesider. Kan oppdragsgiver presisere: (1) hvilke konkrete sider/portaler det gjelder, (2) hvilken teknisk mekanisme som ønskes for synlighet (API/kø/tekstbanner), (3) om det finnes et publiserings-API eller et eksisterende designkrav, og (4) forventet last i sesongtopp (omtrentlig besøkstall/peak) ?

   Hvorfor det er verdt å spørre: Uten konkret kanal, mekanisme og dimensjonering kan leverandøren ikke vurdere arkitektur, ytelseskrav og kostnad for kapasitet/visning.

   Kilde: Bilag 1 pkt. 2.1.5.1 (kapasitetshåndtering i realtid)

7. Bilag 1 pkt. 2.2.2 sier at Moldebadet bruker RFIDarmbånd som adgangsbærer (Menerga er leverandør av port og skap). Kan oppdragsgiver bekrefte hvilke RFID-standarder/protokoller som benyttes (f.eks. frekvens/lesergrensesnitt), hvilke komponenter som er på plass (port/skap/lesere), og om leverandøren skal integrere med Menerga gjennom eksisterende API/SDK/tilkoblingsmetode (og om det finnes dokumentasjon tilgjengelig)?

   Hvorfor det er verdt å spørre: Integrasjonen mot eksisterende RFID/tilgangs-infrastruktur påvirker både leveranseomfang og risiko dramatisk. Leverandøren trenger forutsetninger før pris og plan.

   Kilde: Bilag 1 pkt. 2.2.2 (RFID/videreføring av eksisterende løsning)

8. Bilag 1 pkt. 6.2 krever integrasjon mot kommunens Entra ID for SSO og MFA, men MFA-krav og «hvilke løsningen for MFA som støttes» skal leverandøren beskrive. Kan oppdragsgiver spesifisere hvilke MFA-metoder kommunen bruker/ønsker (f.eks. Microsoft Authenticator, SMS, FIDO2) og om det er krav til Conditional Access-policy eller bare standard Entra-funksjonalitet?

   Hvorfor det er verdt å spørre: MFA-krav kan være teknisk avhengig av tenant-oppsett og policy. Uten dette blir løsningen potensielt ikke kompatibel eller merarbeid oppstår.

   Kilde: Bilag 1 pkt. 6.2 (Entra ID / SSO / MFA)

9. Bilag 1 pkt. 7.1 krever at leverandøren skal angi antall uker fra oppstart til systemet tidligst kan være i drift. Samtidig står i konkurransegrunnlaget del I at leveranse er «September/oktober» og at tidspunktene etter tilbudsfrist er foreløpige. Kan oppdragsgiver angi forventet oppstartdato for implementeringsfasen (dato/uke) og om «systemet tidligst kan være i drift» må være innen en bestemt dato (hard deadline) eller kun en planlagt målsetting?

   Hvorfor det er verdt å spørre: Implementeringsplan og kapasitet/ressursbehov avhenger av faktisk oppstart og eventuelle harde leveransefrister. Dette må avklares for riktig risikopris og gjennomføringsplan.

   Kilde: Konkurransegrunnlag del I pkt. 1.5 (leveranse September/oktober) og Bilag 1 pkt. 7.1

10. Bilag 1 pkt. 4.4 og pkt. 5.3-5.6 beskriver API-arkitektur og sikkerhetsmekanismer (REST/SOAP, OAuth2/WS-Security, TLS, feilhåndtering). Kan oppdragsgiver bekrefte om det allerede finnes konkrete krav til autentisering/autorisasjon for API-er (f.eks. OAuth2-rolle/claims, maskin-til-masking, sertifikatkrav, IP-allowlist), og om kommunen stiller krav til logging/overvåkning av API-kall?

    Hvorfor det er verdt å spørre: API-sikkerhet og infrastrukturkrav (sertifikater, allowlist, logging) kan gi betydelige kostnader. Leverandøren trenger teknisk detaljnivå for å levere korrekt og redusere integrasjonsrisiko.

    Kilde: Bilag 1 pkt. 4.4, pkt. 5.3–5.6 (API standarder og sikkerhet/feilhåndtering)