Elektronisk biladministrasjon og kjørebok

Moss kommune skal anskaffe en skybasert elektronisk biladministrasjon og elektronisk kjørebok for ca. 250 kjøretøy (estimert), inkludert sporingsenheter/GPS og funksjoner for rapportering (bl.a. klimadata til klimaregnskap). Løsningen skal være på norsk, tilfredsstille skatteetatens krav til elektronisk kjørebok, ha integrasjonsmuligheter (inkl. ønske om kobling til Geofence) og understøtte oppgaver som flåteadministrasjon, booking, tilgangsstyring og toveis kommunikasjon med sjåfører. Implementering skal være ferdigstilt og i drift i løpet av 2026. Løsningen forventes brukt 24/7/365. Leverandør skal ha hovedansvar også for deler levert via underleverandører.

• Beskrive hvilke funksjoner systemet innehar (brukervennlighet/intuitivitet), gjerne med korte videosnutter eller på maks 2 A4-sider. (Alle krav skal besvares)Kilde: Bilag 1 – Funksjonelle krav, «Presentasjon» (MR)
• Beskrive løsning for fysisk GPS: løsninger for montering og enkel flytting av brikke mellom kjøretøy. (Oppfølging av sporingsbrikke)Kilde: Bilag 1 – Funksjonelle krav, «Fysisk GPS» (MR)
• Beskrive løsning for Geofence-koblingKilde: Bilag 1 – Funksjonelle krav, «Geofence-system» (BR)
• Beskrive hvilke rapporter/logg/statistikk som kan hentes ut (maks 2 A4-sider) inkl. klimadata/klimaregnskapKilde: Bilag 1 – Funksjonelle krav, «Statistikk»/ «Beskrivelse av…» (MR)
• Beskrive løsning for enkel bruk for administratorer og daglige brukere (maks 2 A4-sider)Kilde: Bilag 1 – Funksjonelle krav, «Enkel å bruke…» (BR)
• Beskrive merverdi for flåteadministrasjon (eksempler: skaderapportering, booking), og egenskaper i systemet (maks 2 A4-sider)Kilde: Bilag 1 – Funksjonelle krav, «Flåteadministrasjon…» (BR)
• Beskrive implementeringsplan for ferdigstillelse i drift ila. 2026: konkret tidsplan fra oppstart installering i bil 1 til hele flåten er «på nett», inkl. roller og forventet tidsbruk fra kundens ressurserKilde: Bilag 1 – Funksjonelle krav, «Implementeringen…» (MR)
• Leverandøren skal gi dokumentasjon som er nødvendig for at kunden skal kunne gjennomføre ROS og DPIAKilde: Bilag 1 – Personvern og informasjonssikkerhet, «Leverandøren skal tilgjengeliggjøre dokumentasjon…» (M)
• Gi oversiktlig skisse og kort beskrivelse av funksjonalitet, arkitektur, grensesnitt og virkemåteKilde: Bilag 1 – Arkitektur og API, «oversiktlig skisse (tegning)…» (MR)
• Beskrive hvordan API-ene er sikret (informasjonsflyt), og hvordan dette er basert på autentisering og autorisasjonKilde: Bilag 1 – Arkitektur og API, «Beskriv hvordan API-ene er sikret…» (BR)
• Beskrive hvordan kundens brukere identifiseres, autentiseres, autoriseres, administreres og hvordan tilgang kan etterprøves (audit)Kilde: Bilag 1 – Tilgangsstyring og autentisering, «Beskriv hvordan…» (MR)
• Beskrive teknisk support: åpning-, respons- og feilrettingstidKilde: Bilag 1 – Tjenestenivå/SLA, «Leverandøren bes beskrive sin tekniske support…» (MR)
• Beskrive varsling og gjennomføring av planlagte vedlikeholds- og servicevinduer, samt rutiner for varsling ved hendelserKilde: Bilag 1 – Tjenestenivå/SLA, «Varsling og gjennomføring…» (MR)
• Legge ved tjenestenivåavtale med utregningsmetode og standardiserte kompensasjonerKilde: Bilag 1 – Tjenestenivå/SLA, «Leverandøren bes legge ved sin Tjenestenivåavtale…» (M)
• Beskrive teknisk løsning for høy tilgjengelighet: tiltak for sikkerhet og tilgjengelighet samt redundans/feiltoleranseKilde: Bilag 1 – Teknisk løsning, «Systemet skal ha høy tilgjengelighet…» (BR)
• Beskrive krav til sertifikater, sikre kommunikasjonsprotokoller, brannmuråpninger, samt eventuelle krav til trådløst nett/infrastruktur/plattform/mobilversjonKilde: Bilag 1 – Teknisk løsning, «Beskriv løsningen sine krav…» (MR)
• Beskrive hvordan kryptering brukes ved lagring og hvordan transport krypteres, samt regime for oppbevaring og tilgang til krypteringsnøklerKilde: Bilag 1 – Sikkerhet, «Beskriv… kryptering…» (BR)
• Beskrive hvordan «security by design» er ivaretatt i løsning og videreutviklingKilde: Bilag 1 – Sikkerhet, «Sikkerhet bør være integrert…» (BR)
• Beskrive planlagte framtidige endringer og utvidelser og planlagt ferdigdatoKilde: Bilag 1 – Forvaltning, «Leverandøren bes beskrive planlagte framtidige endringer…» (BR)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

27.08.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Løsningen skal være skybasert og oversiktlig/enkelt å bruke for både administratorer og daglige brukere; skal følge markedsutvikling med kontinuerlige forbedringer og hyppige oppgraderinger.Kilde: Bilag 1 – Avtalens omfang/overordnet krav
• Til enhver tid ivareta gjeldende lovverk; skal være tilrettelagt for effektiv etablering av integrasjoner; automatiserte prosesser og økende digitalisering.Kilde: Bilag 1 – Avtalens omfang/overordnet krav
• Løsningen må forventes benyttet 24/7/365. Ferdigstilt og klart til bruk innen utgangen av 2026.Kilde: Bilag 1 – Avtalens omfang/Implementering (M), samt «Implementeringen skal være ferdigstilt…» (MR)
• Leverandøren hovedansvarlig for alle deler dersom leverandøren ikke selv leverer alle ytelsene; produsenter trer inn i avtalen som underleverandører.Kilde: Bilag 1 – Avtalens omfang/underleverandøransvar (overordnet)
• Databehandling/personvern: løsning utviklet etter GDPR art. 25 (innebygd personvern/by design); etterleve Personopplysningsloven og GDPR i løsningens levetid.Kilde: Bilag 1 – Personvern og informasjonssikkerhet, «GDPR artikkel 25» (M) og «etterleve…» (M)
• Varslingsplikt ved alvorlige sikkerhetsbrudd: leverandøren skal opplyse kunden så snart avvik oppdages, senest innen 72 timer.Kilde: Bilag 1 – Personvern og informasjonssikkerhet, «plikt til å særskilt opplyse…72 timer» (M)
• Leverandøren skal segregere kommunens data fra andre kunders data (fysisk eller logisk).Kilde: Bilag 1 – Sikkerhet, «segregere kommunens data…» (M)
• Backup: leverandøren skal gjennomføre sikkerhetskopiering og jevnlig verifisere innhold og teste gjenoppretting.Kilde: Bilag 1 – Sikkerhet, «dokumentert prosess for sikkerhetskopiering…» (M)
• Logging/integritet: alle handlinger leverandøren utfører skal logges; loggen skal ikke kunne manipuleres; kunden skal ha tilgang til logger etter behov.Kilde: Bilag 1 – Teknisk løsning, «Alle handlinger…» (M) + loggingkrav (BR)
• Revisjonsrett: kunden har rett til å revidere leverandørens virksomhet knyttet til behandling av kundens data, eller få innsyn i revisjonsrapporter fra uavhengig tredjepart.Kilde: Bilag 1 – Teknisk løsning, «Kunden har rett til å revidere…» (M)
• Testmiljø separat fra produksjon; endringer skal testes og overføres fra testmiljø til produksjon; testmiljø skal ikke bruke kundens produksjonsdata.Kilde: Bilag 1 – Forvaltning, «dokumentert prosess for testing av endringer…» (M)
• Endrings-/forvaltningsprosess: leverandøren bør ha rutiner for hendelseshåndtering gjennom avtaleperioden.Kilde: Bilag 1 – Forvaltning, «hendelseshåndtering» (BR)

• Dokumentteksten gjengir ikke alle SLA/kompensasjonsdetaljer; kun at SLA skal vedlegges og at leverandør skal beskrive support/vedlikehold og legge ved tjenestenivåavtale (uten satser i teksten).
• Tildelingskriterier er ikke oppgitt i den vedlagte teksten; kun kravtyper (M/MR/BR) og kravbeskrivelser.
• Krav om implementeringsleveranser (f.eks. godkjenningsprøve/leveransemelding) beskrives kun indirekte via henvisning til generelle avtaletekster/bilag 3, men detaljer om milepæler/dagbot er ikke inkludert i kravspesifikasjonen.
• Antatt startdato/avtalevarighet (f.eks. «Oppstart av tjenesten 01.01.2027») finnes i annen tekst (ssa-l_bilag 5), men relateres ikke eksplisitt til Bilag 1-kravene i utdraget.

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 fremgår kravet «Implementeringen skal være ferdigstilt og i drift ila. 2026», og i bilag 5 punkt 5.1 er oppstart av tjenesten oppgitt til 01.01.2027. Kan dere bekrefte hvordan disse datoene skal forstås i sammenheng (hva som menes med «ferdig implementert» vs. når avtalen/leveransen anses som etablert/kan faktureres), og vise til hvilke konkrete milepæler/leveransemeldinger som gjelder?

   Hvorfor det er verdt å spørre: Leverandøren må forstå når oppstart/fakturering/leveransemelding skjer og hvilke leverings-/godkjenningsmilepæler som utløser dagbot/kompensasjon.

   Kilde: Bilag 1 (Implementeringen skal være ferdigstilt og i drift ila. 2026) og bilag 5 punkt 5.1 (Oppstart av tjenesten 01.01.2027), samt SSA-L punkt 3.2–3.3.

2. Bilag 4 slår fast at «Leverandørens SLA skal vedlegges», men i det mottatte materialet er kun henvisningen synlig. Kan dere sende vedlagt/opplyse hvilken SLA som er forventet (inkl. oppetidsmål, hendelsesklassifisering, respons- og feilrettingstider) og hvordan standardiserte kompensasjoner i bilag 4 beregnes (satser/utregningsmetode), slik at vi kan prise riktig?

   Hvorfor det er verdt å spørre: For å prise riktig må leverandøren vite eksakte SLA-nivåer og kompensasjonsberegning; dette er avgjørende for kommersiell risiko.

   Kilde: Bilag 4: Tjenestenivå med standardiserte kompensasjoner (Avtalens punkt 2.1) og SSA-L punkt 9.2.4.

3. I SSA-L punkt 9.2.3 beskrives at dagbot gjelder ved forsinkelse, og teksten sier «andre dagbotsatser… kan avtales i bilag 3». I det mottatte bilaget 3 er det bare «[Eventuell tekst]» og ingen konkrete satser/frist knyttet til milepæler. Kan dere oppgi konkrete dagbøter (dagbotssats, beregningsgrunnlag, maks varighet) og hvilke milepæler som er dagbotbelagte i denne anskaffelsen?

   Hvorfor det er verdt å spørre: Dagbot kan bli stor kostnadsdriver hvis milepæler og satser ikke er kjent; leverandøren må kunne gjøre realistisk prising og planlegging.

   Kilde: SSA-L punkt 9.2.3 (Dagbot ved forsinkelse) og bilag 3-overskriftene (inkl. henvisning «Dagbot ved forsinkelse»).

4. I bilag 1 er det flere MR/M-krav som forutsetter konkrete prosesser/leveranser, men redegjørelsesformatet er ikke presisert. Kan dere bekrefte hvilket omfang dere forventer for «beskrivelse… maks 2 A4-sider» (f.eks. om det skal være én samlet A4-pakke per krav, eller om det kan kombineres på tvers av nært beslektede krav), og om videoer er valgfritt eller vil inngå i evaluering?

   Hvorfor det er verdt å spørre: Leverandøren trenger tydelig ramme for dokumentasjons-/besvarelsesformat for å levere innenfor konkurransens krav og risiko for avvisning/negativ evaluering.

   Kilde: Bilag 1 (Presentasjon; krav med maks 2 A4-sider og eksempel med «korte videosnutter»).

5. Krav i bilag 1 sier at løsningen skal tilfredsstille skatteetatens krav til elektronisk kjørebok «til enhver tid». Hvilken konkret skatteetatlig løsning/kravreferanse (f.eks. tekniske spesifikasjoner/perioder/rapportformat) er det dere forventer at leverandøren oppdaterer løsningen i henhold til, og hvordan vil dere håndtere endringer som krever større utvikling hos leverandør (inngår dette i standardoppgraderinger/vedlikehold, eller blir det bestilt som «ytterligere utvikling» etter SSA-L punkt 3.6)?

   Hvorfor det er verdt å spørre: For å prise riktig må leverandøren forstå om regulatoriske endringer er inkludert i løpende leveranse/vedlikehold eller kan bli etterbestilt som utvikling.

   Kilde: Bilag 1 (Elektronisk kjørebok – tilfredsstille skatteetatens krav «til enhver tid»), samt SSA-L punkt 3.5–3.6.

6. I bilag 1 står det at «Hvis Leverandøren ikke selv leverer alle ytelsene… produsenter … trer inn i avtalen som underleverandører». Kan dere bekrefte (i) hvilke konkrete deler som typisk vil være tredjeparts-/produsentytelser i denne anskaffelsen, og (ii) hvilke kontraktsmessige konsekvenser dere forventer (f.eks. at tredjepart er part, eller at underleverandørforpliktelser vedlegges via bilag 9), slik at vi vet hva som må dokumenteres ved tilbud/kontraktsinngåelse?

   Hvorfor det er verdt å spørre: Leverandøren må forstå tredjepartsrollen for å sikre korrekt risikoallokering, dokumentasjonsplikt og eventuelle ansvarsoverføringer.

   Kilde: Bilag 1 (Avsnitt om underleverandører/produsenter som trer inn i avtalen) og SSA-L punkt 2.2, bilag 9.

7. Bilag 1 har flere krav knyttet til integrasjoner og API (geofence-tilkobling, standardiserte og åpne grensesnitt, samt at Moss «ønsker» kobling til Geofence-system). Kan dere beskrive hvilke eksisterende systemer Moss har i dag som skal integreres (navn/versjon), hvilke datatyper som skal utveksles (f.eks. geofence-hendelser, hendelseslogging, kjøretøy-/sjåførdata), og eventuelle test-/godkjenningskriterier for integrasjonen?

   Hvorfor det er verdt å spørre: Integrasjonsomfang påvirker både plan for etablering og pris (utvikling, sikkerhet, test og godkjenning).

   Kilde: Bilag 1 (Geofence-kobling, API/arkitektur, integrasjoner) og SSA-L punkt 3.1–3.4.

8. Bilag 6 (Samlet pris og prisbestemmelser) er ikke med i utdraget. Prisrisikopunkter som revisjon i tjenestebruk og eventuelle prisendringer ved CPI/avgifter er beskrevet i SSA-L, men for denne anskaffelsen må det avklares hva som faktisk gjelder. Kan dere oppgi hvilke prisbestemmelser som er avtalt i bilag 6 (timepriser for videreutvikling, evt. prisreguleringer/indeks, og eventuelle vilkår for skalering ved endret antall kjøretøy/pool), slik at vi kan prise variable kostnader korrekt?

   Hvorfor det er verdt å spørre: Prisarkitektur og eventuelle justeringsmekanismer må være kjent før tilbudsprising; ellers blir priskalkylen usikker og kan gi feil tilbudspris.

   Kilde: SSA-L punkt 4.5 og 5.2–5.4 (prisendringer/avbestilling) samt bilag 3-1 prisskjema som refererer til bilag 1 pkt. 1.8/1.9/1.14/1.21 og SSA-L punkt 4.1 og 4.6 (bilag 6).

9. Krav i bilag 1 og SSA-L legger opp til revidering/tilgang til logg, revisjonsrapporter og sikkerhetstest. Kan dere klargjøre (i) hvilke rapporter som skal kunne deles (f.eks. årlige penetrasjonstester, SOC/ISO-erklæringer, risikovurderingsdokumenter), (ii) forventet frekvens og (iii) prosess for forespørsel/levering (format, tid, personopplysningshensyn), slik at vi kan vurdere kost og ressursbruk?

   Hvorfor det er verdt å spørre: Sikkerhet-/revisjonsleveranser kan være ressurskrevende; tydelighet reduserer kommersiell risiko og bidrar til riktig kostnadsestimat.

   Kilde: Bilag 1 (Forvaltning/sikkerhet: logging, revidere virksomhet, sikkerhetstesting og risikovurderinger) og SSA-L punkt 11.3 (taushet) samt SSA-L punkt 4.2/6 (dokumentasjon/tilgjengelighet).