Drift av båtrute Træna Lokal 20.02.2027-31.03.2037

Dokumentene beskriver Nordland fylkeskommunes datastrategi og krav til datatilgang/deling (Bilag 1c), samt databehandleravtale (Bilag 5). Det foreligger også kontraktsvilkår for båt (Bilag 0) som bl.a. omhandler drift, billettering, GDPR og data-/rapporteringskrav, og en teknisk byggespesifikasjon for et fartøy (Vedlegg 2a) med omfattende krav til dokumentasjon, prøving, universell utforming m.m.

• Operatør skal i oppstartsmøte presentere en plan for hvordan kontraktens forpliktelser skal dokumenteres.Kilde: Bilag 0 – Kontraktsvilkår båt, punkt 3.3 Oppstarts forberedelser
• Oppdragsgiver kan frem til oppstart kreve skriftlig statusrapport for forberedelse til oppstart. Frist: 1 uke.Kilde: Bilag 0 – Kontraktsvilkår båt, punkt 3.3 Oppstarts forberedelser
• Innen 1 måned før driftsoppstart skal operatør ha tegnet P&I-forsikring og kasko-forsikring.Kilde: Bilag 0 – Kontraktsvilkår båt, punkt 3.3 Oppstarts forberedelser
• Samtidig som garantiene sendes til oppdragsgiver skal politiattest (daglig leder) samt attest for skatt og merverdiavg sendes inn.Kilde: Bilag 0 – Kontraktsvilkår båt, punkt 5.3 Garanti og løyveforpliktelser
• (Databehandleravtale) Databehandler skal dokumentere rutiner og tiltak; dokumentasjon skal oppbevares/ajourholdes så lenge avtalen består og gjøres tilgjengelig ved forespørsel.Kilde: Bilag 5 – Databehandleravtale, punkt C.3 Dokumentasjon (og tilhørende instruks)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

31.08.2026

Språk

norsk, English

Elektronisk katalog

Ikke tillatt

• Operatør må følge ITxPT-standarden (gjeldende versjon) for IT-utstyr om bord, inkludert implementasjon av minimumsmodulene.Kilde: Bilag 1c – Datastrategi, punkt 3.1 ITxPT
• Operatør må dekke alle kostnader for utskiftning av eget utstyr for å følge gjeldende ITxPT-versjoner.Kilde: Bilag 1c – Datastrategi, punkt 3.1 ITxPT
• Arkitekturen skal til enhver tid reflektere gjeldende ITxPT-versjon slik at nødvendig funksjonalitet støttes.Kilde: Bilag 1c – Datastrategi, punkt 3.1 ITxPT
• Operatør skal bruke SIRI-formatet for sanntidsdata (gjeldende versjon).Kilde: Bilag 1c – Datastrategi, punkt 3.1.1 Sanntidsdata
• All rutedata skal hentes fra Entur i NeTEx-format (Norsk profil). Relevant maskinvare skal oppdateres med rutedata jevnlig (minimum én gang per uke) og ved forespørsel.Kilde: Bilag 1c – Datastrategi, punkt 3.2 Rutedata
• Operatør skal levere vognløpsdata i NeTEx-format (sammenkobling kan endre ansvar i anbudsperioden).Kilde: Bilag 1c – Datastrategi, punkt 3.2 Rutedata
• Operatør skal tilrettelegge for at oppdragsgiver til enhver tid får data på energieffektivitet og utslipp via Consat (kjøretøy) og Shiplog (fartøy).Kilde: Bilag 1c – Datastrategi, punkt 3.3 Miljø
• Operatør skal sikre at datakvaliteten er tilfredsstillende ved jevnlige kontroller (stikkprøver, avstemming, andre kontroller).Kilde: Bilag 1c – Datastrategi, punkt 3.4 Datakvalitet
• Ved feil i data skal dette meldes uten ugrunnet opphold til oppdragsgiver, med forslag til løsning.Kilde: Bilag 1c – Datastrategi, punkt 3.4 Datakvalitet
• Oppdragsgiver eier all data som produseres gjennom etterspurte tjenester.Kilde: Bilag 1c – Datastrategi, punkt 6 Eierskap til data
• Operatør som leverer tjenester på vegne av oppdragsgiver skal tilgjengeliggjøre all data som blir produsert gjennom leveransen.Kilde: Bilag 1c – Datastrategi, punkt 7 Tilgang til data
• Data tilgjengeliggjøres via enten direkte tilkobling til database eller manuell innsending via Microsoft Forms.Kilde: Bilag 1c – Datastrategi, punkt 7 Tilgang til data
• Ved direkte tilkobling skal operatør åpne range av IP-adresser mot Microsoft sitt datasenter (uavhengig av lokasjon).Kilde: Bilag 1c – Datastrategi, punkt 7 Tilgang til data (alternativ 1)
• Data skal tilgjengeliggjøres daglig.Kilde: Bilag 1c – Datastrategi, punkt 7.1 Frekvens for oppdatering av data
• For godsfrakt tillates månedlig rapportering; frist for rapportering er 5. i påfølgende måned.Kilde: Bilag 1c – Datastrategi, punkt 7.1 Frekvens for oppdatering av data
• For all godsfrakt skal det tilgjengeliggjøres data på fra-til strekning, dato, kategori og vekt.Kilde: Bilag 1c – Datastrategi, punkt 7.2 Godsfrakt
• Oppdragsgiver har rett til å dele data; persontilgang skjer via Power BI, og det gis ingen direkte tilgang til oppdragsgivers database.Kilde: Bilag 1c – Datastrategi, punkt 8 Deling av data
• Databehandler skal kun behandle personopplysninger innenfor omfang/formål beskrevet i hovedavtalen/databehandleravtalen.Kilde: Bilag 5 – Databehandleravtale, punkt C.1 Behandlingens omfang og formål
• Databehandler skal etablere og forvalte et egnet styringssystem for informasjonssikkerhet og ha tilstrekkelige sikkerhetstiltak.Kilde: Bilag 5 – Databehandleravtale, punkt C.2 Sikkerhet ved behandlingen
• Databehandling kan ikke utføres på/med tilgang fra andre lokasjoner enn angitt (uten forhåndsgodkjenning).Kilde: Bilag 5 – Databehandleravtale, punkt C.4 Overføring av personopplysninger – lokasjon og tilgang
• Databehandler har slettingsfrist: alle personopplysninger skal slettes uten ugrunnet opphold og senest innen 90 kalenderdager etter opphør av hovedavtalen.Kilde: Bilag 5 – Databehandleravtale, punkt C.6 Sletting og tilbakelevering (alternativ valgt)

• Bilag 0 viser kun innhold og del av punkt 5.1-5.3; øvrige drift-/data-/GDPR-krav (f.eks. punkt 6.18 Data og rapportering og 6.19 GDPR) er ikke med i utdraget, så full kravliste kan ikke hentes fra teksten.
• I Bilag 1c finnes blant annet krav om sanntid/rutedata/miljø/datakvalitet og tilgang til data, men detaljer om konkrete rapporteringsformat/abonnementer (utover NeTEx/SIRI/ConSAT/Shiplog og tilkoblingsalternativer) er ikke spesifisert i utdraget.
• Databehandleravtalen har oppgitte typer personopplysninger/kategorier og sikkerhetsnivå, men konkrete detaljer i Bilag B.2 (under databehandlere) er ikke utfylt (plassholdere).

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 0 kap. 3.1 og 3.3 vises det til oppstartsdato og kontraktens varighet i Bilag 1a. Kan dere sende/oppgi eksakt oppstartsdato og kontraktens varighet (inkl. eventuelle opsjoner), slik at vi kan planlegge bemanning, forsikringer og oppstartstiltak?

   Hvorfor det er verdt å spørre: Riktig prising og planlegging av oppstartsforberedelser (statusmøter, rapporter, forsikring) avhenger av eksakte datoer og varighet.

   Kilde: Bilag 0, kap. 3.1 og 3.3

2. I Bilag 0 kap. 6.10 Billettering står det at operatør skal bruke systemer oppdragsgiver stiller til rådighet, og at rutiner kan endres uten endring i godtgjørelse. Hvilke konkrete komponenter inngår fra oppdragsgiver (f.eks. Microsoft Forms-skjemaer for avvik/rapportering, API/tilkobling, kontaktpunkt «superbruker»), og hvilke innleveringer/leveranser forventes fra operatør før og etter oppstart?

   Hvorfor det er verdt å spørre: Konkret innleveringskrav og teknisk oppsett for billettering/dataintegrasjon mangler i utdraget, og må avklares for å prise riktig arbeid og risiko.

   Kilde: Bilag 0, kap. 6.10

3. I Bilag 0 kap. 6.18 Data og rapportering fremgår det at det «skal rapporteres ... og at det der det er mulig» skal skje via direkte tilkobling mellom operatør sitt kildesystem og oppdragsgivers dataplattform. Kan dere spesifisere hvilke datakategorier som MÅ leveres via direkte tilkobling (og hvilke som kan leveres via manuelle/malbaserte innrapporteringer), samt hvilke filformater/krav til hendelsesfrekvens dere forventer for: produksjon, passasjerer per mellomsted, regularitet, reservefartøy, utslipp/drivstoff, og HMS/sykefravær?

   Hvorfor det er verdt å spørre: Utydelig integrasjons- og rapporteringsomfang påvirker både teknisk løsning og kostnader (implementasjon, drift og datakvalitet).

   Kilde: Bilag 0, kap. 6.18

4. I Bilag 0 kap. 6.19 GDPR står det at databehandleravtale skal fylles ut ved behov, og det henvises til DFØ-maler. Kan dere bekrefte hvilke datatyper som oppdragsgiver pålegger at operatør samler inn/lagrer (f.eks. reisendeopplysninger), og levere ferdig utfylt databehandleravtale-mal eller liste over obligatoriske felter som operatør må fylle (navn/organisasjonsnr./underdatabehandlere og geografiske lokasjoner)?

   Hvorfor det er verdt å spørre: Uten konkrete GDPR-omfang og utfyllingskrav kan leverandøren ikke sikre etterlevelse eller riktig ressursbruk.

   Kilde: Bilag 0, kap. 6.19

5. I Bilag 0 kap. 11 Sanksjoner og kap. 8.2–8.5 vises det til Bilag 1d (satser og terskler), men terskler/satser fremgår ikke i utdraget her. Kan dere oppgi/oversende Bilag 1d og i tillegg tydeliggjøre hvilke brudd som utløser sanksjoner innenfor (a) billettering/dataintegrasjon/avvik, (b) regularitet/rapportering, og (c) miljøavregning (herunder hva som regnes som «avvik på over +10%» og beregningsgrunnlag)?

   Hvorfor det er verdt å spørre: Manglende sanksjonsgrunnlag gjør det vanskelig å prise risikopåslag og forstå konsekvensene av eventuelle avvik.

   Kilde: Bilag 0, kap. 11 og kap. 8.2–8.5

6. I Bilag 0 kap. 6.3–6.4 fremgår det at passasjerregistrering kan gjøres automatisk (kamera/sensor) og at manuell telling skal skje ved nedetid. Hva er akseptkriteriet for «nedetid» (varighet/terskel), og hvordan skal manuell telling gjennomføres (hyppighet, metode, verifisering og hvem som skal kvalitetssikre resultatet)?

   Hvorfor det er verdt å spørre: Prising og drift krever klar standard for drift ved fall i automatisert telleløsning.

   Kilde: Bilag 0, kap. 6.4

7. I Bilag 0 kap. 6.8 om kai og avgifter: kan dere spesifisere (1) hvilke kostnader som gjelder for «fylkeskommunens fergekaier» vederlagsfritt etter avtale, (2) hvordan operatør skal håndtere situasjoner der operatør må inngå avtaler med kaieier (godkjenningsprosess, frister og ansvar for kostnadsnivå), og (3) om det finnes konkrete retningslinjer for «liggekai»/maks avvik som godkjennes av oppdragsgiver?

   Hvorfor det er verdt å spørre: Kostnadsbilde og prosessrisiko for kaileie/avtaler kan være betydelig og bør avklares før tilbud.

   Kilde: Bilag 0, kap. 6.8

8. I Bilag 0 kap. 6.23 Beredskap står det at planen skal inkludere «tiltak for å sikre oppdragsgivers billettinntekter». Hvilke konkrete billettinntekts-scenarioer skal beredskapsplanen adressere (f.eks. tap ved systemstans, betalingsavvik, manuell billettprosedyre), og finnes det en standard prosedyre for hvordan oppdragsgiver/operatør skal sikre inntekter ved billetterings- eller dataplattform-feil?

   Hvorfor det er verdt å spørre: Beredskapskravet er formulert bredt; konkret innhold er nødvendig for å vurdere omfang og dokumentasjon.

   Kilde: Bilag 0, kap. 6.23

9. I Bilag 0 kap. 3.2 Opsjon: Det fremgår at oppdragsgiver kan løse ut opsjoner, men opsjonens innhold/tidsrom er beskrevet i Bilag 1a. Kan dere beskrive hvilke opsjoner som finnes (volum/linjer/samband, varighet, utløsningsvilkår) og hvilken pris-/reguleringsmekanisme som gjelder for hver opsjon?

   Hvorfor det er verdt å spørre: Opsjonsstruktur påvirker prising, bemanningsmodell og risikodeling.

   Kilde: Bilag 0, kap. 3.2

10. I Bilag 0 kap. 8.4 Produksjonsavregning: dere viser til satser og at rapportering skal utarbeides etter mal fra oppdragsgiver. Kan dere oversende/gi eksempel på avregningsmal og rapporteringsmal (inkl. feltliste) og avklare hvordan «merproduksjon/mindreproduksjon» beregnes når ruteplan endres av oppdragsgiver i kontraktsperioden?

    Hvorfor det er verdt å spørre: For å kunne gi korrekt tilbud og unngå tvister om avregningsgrunnlag må beregningslogikk og rapporteringsformat være kjent.

    Kilde: Bilag 0, kap. 8.4 og kap. 3.4