Nye nettsider

Lier kommune skal anskaffe nye nettsider som en skytjeneste (SaaS). Prosjektet omfatter planlegging, testing, implementering, opplæring av redaktører/administratorer, lansering og drift/vedlikehold/utvikling, samt migrering av innhold fra dagens nettsider (lier.kommune.no og lieropplevelser.no) i én løsning. Det er behov for universell utforming (WCAG), personvern og informasjonssikkerhet, integrasjoner mot eksisterende fagsystemer (ikke uttømmende liste), samt mulighet for trafikkmåling og avansert internsøk (inkl. KI-funksjonalitet). Fremdrift: ønsket ferdigstillelse innen sommer 2027.

• (Ingen eksplisitte kvalifikasjonskrav identifisert i den vedlagte teksten.)

  Dokumentasjon: —

  Kilde: Utdrag: Behovsbeskrivelse/vedlegg/databehandleravtale/prisskjema (mangler oppgitt kvalifikasjonsdel)

• (Ingen eksplisitte innleveringskrav til tilbudet identifisert i den vedlagte teksten.)Kilde: Utdrag om behov, databehandleravtale, prisskjema og innsyn/innleveringsveileder (ingen kravliste for dokumentinnlevering er inkludert).

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

23.09.2026

Språk

norsk

Elektronisk katalog

Tillatt

• Leveranse som skytjeneste (SaaS), med leverandørens ansvar for drift, vedlikehold og oppdateringer; oppdragsgiver skal ikke ha behov for lokal installasjon/oppdatering/vedlikehold.Kilde: Behovsliste pkt. 5.2; SSA-L/avtaletekst punkt om as-a-service (generell avtaletekst)
• Formålsavgrensning: personopplysninger skal kun behandles i omfang og for formål beskrevet i hovedavtalen/dba-bilag; databehandler har ikke råderett til egne formål.Kilde: Bilag C/Instruks: «Personopplysningene skal utelukkende…»
• Sikkerhet: databehandler skal iverksette egnede tekniske og organisatoriske tiltak og opprettholde et egnet sikkerhetsnivå; dokumentasjon og risikovurdering skal kunne fremlegges på forespørsel.Kilde: dba_generell_avtaletekst_2020_no punkt 7; Bilag C «Sikkerhet…», «Styringssystem…», «Dokumentasjon»
• Styringssystem for informasjonssikkerhet (ISMS) og sikkerhetstiltak iht. bilag C; dokumentasjon skal oppbevares/ajourholdes.Kilde: Bilag C «Styringssystem for informasjonssikkerhet» og «Dokumentasjon»
• Bruk av underdatabehandlere krever forhåndstillatelse etter Bilag B; endringer må varsles og evt. kan kreve skriftlig godkjenning (saklig grunn for avslag).Kilde: Bilag B «Betingelser…» + generell avtaletekst punkt 9
• Begrensning for lokasjon/tilgang til personopplysninger: behandling på andre lokasjoner eller med tilgang fra andre lokasjoner enn angitt i bilag B.2 krever skriftlig forhåndsgodkjenning.Kilde: Bilag C «Overføring av personopplysninger - Lokasjon for behandling og tilgang»
• Revisjon/tilsyn: behandlingsansvarlig kan utføre revisjon hos databehandler (maks én gang i året som hovedregel) og/eller kreve ekstern revisor/attestasjon (årlig) etter valg i bilag C.Kilde: Bilag C «Rutiner for revisjon og tilsyn»; dba-generell avtaletekst punkt 11
• Sletting/tilbakelevering ved avtalens opphør: enten sletting innen 90 dager eller tilbakelevering + sletting innen 30 dager (valg i bilag C).Kilde: Bilag C «Sletting og tilbakelevering…»; dba-generell avtaletekst punkt 12
• Varsling om sikkerhetsbrudd: databehandler skal uten ugrunnet opphold underrette behandlingsansvarlig, inkludert krav til innhold (art, kategorier/antall, kontaktpunkt, sannsynlige konsekvenser, tiltak).Kilde: dba_generell_avtaletekst_2020_no punkt 8
• Overføring til land utenfor EØS kun etter skriftlig godkjenning og oppfyllelse av overføringsgrunnlag/garantier (f.eks. EU-kommisjonens tilstrekkelighetsbeslutning eller EU Model Clauses).Kilde: dba_generell_avtaletekst_2020_no punkt 10; Bilag B/Vilkår for underdatabehandlere
• Datarettigheter/tilgjengeliggjøring ved avtalens opphør: leverandør skal tilgjengeliggjøre kundedata på allment tilgjengelig og maskinlesbart format med opprinnelige strukturer og metadata intakt; leverandør har ikke tilbakeholdsrett i kundens data.Kilde: SSA-L «rettigheter til data» samt «Leverandøren har ikke under noen omstendighet rett til å utøve tilbakeholdsrett…»
• Rekonstruksjon ved tap/ødeleggelse av data: leverandør skal uten ugrunnet opphold gjenopprette og eventuelt rekonstruere data innenfor ansvar.Kilde: SSA-L «Rekonstruksjon av data»
• Ved mislighold: avhjelp/plikt til å bringe tjenesten i samsvar; Kunden kan kreve prisavslag/hevning ved vesentlig mislighold; dagbot kan gjelde ved forsinkelse.Kilde: SSA-L punkt 9 (mislighold og sanksjoner), inkl. dagbot-regel

• Utdraget inneholder ikke konkurransens egne kvalifikasjonskrav- og tildelingskriterieavsnitt (trolig ligger dette i andre dokumenter/kapitler som ikke er inkludert).
• Databehandleravtalen/bilagene inneholder flere avkryssbare valg (f.eks. sikkerhetsnivå, varighet og slettemetode), men utførte valg fremgår ikke av utdraget (placeholder/«velg ett alternativ»).
• Behovsbeskrivelse og vedlegg viser ikke eksplisitte SLA-tall eller konkrete leveransemilepæler (kun at det finnes «tjenestenivå med standardiserte kompensasjoner» i SSA-L-bilag 4).

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 SSA-L punkt 3.3 (godkjenningsprøve/leveringsdag) og punkt 9.2.1 (prisavslag ved mislighold): Kan dere bekrefte at dere i bilag 3 har fastsatt konkrete milepæler/leveransefrister som utløser dagbot, og at definisjonene av A/B/C-feil i bilag 3 (hvis dere har presisert dem) også knyttes til hva som anses som vesentlig mislighold/heving? Hvis dere har presiseringer i bilag 3, ber vi om at dere enten viser dem eller beskriver kort hvordan disse reglene virker sammen.

   Hvorfor det er verdt å spørre: Vi må forstå sammenhengen mellom godkjenningsprøve, feilklassifisering, dagbøter og terskler for prisavslag/heving for å prise riktig risiko i prosjektet.

   Kilde: SSA-L punkt 3.3, 9.2.1 og bilag 3 (Leveranse/milepæler og feildefinisjoner).

2. SSA-L punkt 9.2.4 (økonomisk kompensasjon ved brudd på avtalt tjenestenivå): Kan dere spesifisere hvilke konkrete “standardiserte kompensasjoner” som gjelder i bilag 4, og bekrefte om kompensasjonene gjelder per hendelse, per dag, eller per måleperiode (og hva som er grunnlaget for beregningen)?

   Hvorfor det er verdt å spørre: Vi skal kunne prise og dimensjonere drift/support med riktig forventet kompensasjon ved brudd på tjenestenivå.

   Kilde: SSA-L punkt 9.2.4 samt bilag 4 (tjenestenivå med standardiserte kompensasjoner).

3. Behovsbeskrivelse (Vedlegg 1) og vedlegg 2 pkt. 5.2–5.6: Når dere skriver at løsningen er en skytjeneste og at dere skal varsle ved planlagt vedlikehold og uforutsette hendelser (inkl. feilmelding på nettsiden): Kan dere bekrefte hvilke varslingstider som gjelder (f.eks. dager/timer før vedlikehold) og hvilke tilgjengelighetsmål dere faktisk legger til grunn (samt om det er målt i minutter per måned/år)?

   Hvorfor det er verdt å spørre: Uten konkrete SLA-/tilgjengelighetsmål og varslingstider kan vi ikke prise kapasitet, overvåking og hendelseshåndtering.

   Kilde: Vedlegg 2 pkt. 5.2 og 5.6; samt Vedlegg 1 “Fremdrift og kontaktpunkter” og SSA-L bilag 4 (tjenestenivå).

4. Vedlegg 2 (Kontinuerlig forvaltning) pkt. 4.1–4.2 og Vedlegg 2 (Funksjonalitet) pkt. 2.2: Når dere beskriver avansert internsøk som “benytter mulighetene … innen KI” og at dere ønsker nøkkelstatistikk fra både sider og internsøk: Kan dere beskrive hvilke analyser/rapporter dere forventer at løsningen leverer (f.eks. søketermer som ikke gir treff, treffprosent, “did you find”/konverteringer, gjenfinningstid), og om kommunen selv skal kunne konfigurere/optimalisere søket via redaktørrollen?

   Hvorfor det er verdt å spørre: Dette påvirker både funksjonell scope, logging/rapportering og hvor mye “KI”-styring vi må legge til rette for i redaktørgrensesnittet.

   Kilde: Vedlegg 2 pkt. 2.2, 2.5, 4.1 og 4.2; samt behovsbeskrivelse pkt. 3.4 og 6 (integrasjoner/forvaltning).

5. Vedlegg 2 pkt. 6.8 (migrering): Kan dere gi et estimat på omfang og kompleksitet for migreringen (f.eks. ca. antall sider/underdeler, antall dokumenter i html eller filbibliotek, antall språk/metadata, og om “liasjon” mellom lier.kommune.no og lieropplevelser.no er 1:1 eller krever mapping/omstrukturering)?

   Hvorfor det er verdt å spørre: Migrationsarbeidet er priset som en fast linje (“Konvertering/Migrering av data”); vi trenger riktig volum/kompleksitet for å prise riktig margin og ressursbruk.

   Kilde: Vedlegg 2 pkt. 6.8 og Prisskjema linje 2 (Konvertering/Migrering av data).

6. Prisskjema linje 5 (Pris for integrasjon mot fagsystemer per integrasjon): I Vedlegg 1 “Integrasjoner” gir dere en liste over fagsystemer (ikke uttømmende). Kan dere bekrefte hvor mange av integrasjonene dere antar er “kjente integrasjoner” inkludert i linje 1 (total implementering), og hvor mange som typisk vil prises som “ukjente intergrasjoner” i linje 5? Hvis dere ikke kan dele opp eksakt antall nå, ber vi om at dere beskriver hvordan dere vil avgrense “integrasjon” som prissettende enhet.

   Hvorfor det er verdt å spørre: Uavklart avgrensning mellom inkluderte og opsjons-/tilleggsintegrasjoner påvirker tilbudspris direkte og leverandørens risiko.

   Kilde: Prisskjema (linje 1 og 5) samt Vedlegg 1 “Integrasjoner” og SSA-L punkt 2.1/omfang (bilag 1/2).

7. Databehandleravtalen (dba_generell_avtaletekst_2020_no og Vedlegg D): Bilag C har feltvalg for sikkerhetsnivå (“høyt”/“ikke høyt”), varighet (tidsbegrenset/ikke tidsbegrenset), og regler for sletting/tilbakelevering (f.eks. senest innen 90 dager vs tilbakelevering først). I utdraget ser vi bare at felter/valg ligger som mal/placeholder. Kan dere bekrefte hvilke konkrete alternativer som gjelder for denne konkurransen (sikkerhetsnivå, varighet, og slettemekanisme/tidsfrister)?

   Hvorfor det er verdt å spørre: Personvern- og sikkerhetsforpliktelser påvirker kostnader og implementasjonsvalg; vi må vite hvilke faktiske opsjoner dere har valgt.

   Kilde: Databehandleravtale bilag (spesielt Vedlegg C “Angivelse av sikkerhetsnivå” og “Sletting og tilbakelevering …”; samt dba_generell_avtaletekst_2020_no punkt 6 og 12).

8. Opsjoner i prisskjema linje 7–8 (Chat): Kan dere presisere om “Chat (jf. vedlegg 2 pkt. 7.1)” kun er en implementasjons-opsjon (linje 7) og at årlig drift/vedlikehold/development (linje 8) forutsetter samme chat-funksjon? Videre: Er chat inkludert i evalueringen kun dersom opsjonen aktiveres, og hvilke SLA-/tjenestenivåkrav gjelder for chat hvis opsjonen aktiveres?

   Hvorfor det er verdt å spørre: Opsjonsmekanismen må forstås for å prise implementering og drift korrekt og for å vite hvilke tjenestenivåkrav som gjelder for den ekstra funksjonaliteten.

   Kilde: Prisskjema linje 7–8; Vedlegg 2 pkt. 7.1 (Opsjoner); samt SSA-L bilag 4/kompensasjoner.

9. SSA-L punkt 5.2 (Avbestilling) og Prisskjema: Når dere sier at Kunden kan avbestille med 3 måneders varsel, og at det skal betales (1) gjennomført del, (2) direkte dokumenterte kostnader for omdisponering, (3) andre direkte dokumenterte kostnader, samt (4) avbestillingsgebyr 10 % av vederlaget fakturert de siste tre måneder: Kan dere bekrefte hvordan dette skal beregnes for en løsning med både fast implementering og årlige vedlikeholds-/utviklingskostnader (linje 1–4) samt eventuelle opsjoner (chat)?

   Hvorfor det er verdt å spørre: Uten avklarte beregningsprinsipper kan risikoen ved avbestilling bli feilpriset, særlig for SaaS/årlig kostnadsdel.

   Kilde: SSA-L punkt 5.2; Prisskjema linje 1–4 og 7–8.