Anskaffelse: Rammeavtale for utvikling og drift av geodatainfrastruktur

Fiskeridirektoratet skal inngå rammeavtale for utvikling og drift av geodatainfrastruktur (produktet Yggdrasil med flere kartløsninger). Anskaffelsen gjennomføres som åpen anbudskonkurranse over EØS-terskel, med rammeavtalens varighet 2 + 1 + 1 år (maks 4 år) eller til økonomisk ramme er nådd. Total verdi er oppgitt til 12.000.000 eks. mva. Tildeling skjer etter funksjonalitet/andre forhold (40%), kompetanse/erfaring (20%), kapasitet/tilgjengelighet (15%) og pris (25%).

• Leverandøren skal ha ordnede forhold med hensyn til betaling av skatt, arbeidsgiveravgift og merverdiavgift.

  Dokumentasjon: Skatteattest ikke eldre enn 6 måneder (FOA § 7-2 (2)); norske leverandører kan bestille via RF-1316 i Altinn, utenlandske leverandører med tilsvarende attest/erklæring signert av økonomiansvarlig/økonomidirektør.

  Kilde: Konkurransegrunnlag, pkt. 4.2.1 Skatteattest
• Leverandøren skal være et lovlig etablert foretak.

  Dokumentasjon: Firmaattest (norske) eller bekreftelse på registrering i foretaks-/bransjeregister i leverandørens etableringsland (utenlandske).

  Kilde: Konkurransegrunnlag, pkt. 4.2.2 Firmaattest
• Utfylle elektronisk egenerklæringsskjema (ESPD) og bekrefte oppfyllelse av kvalifikasjonskrav.

  Dokumentasjon: Elektronisk egenerklæringsskjema i EU-Supply KGV/CTM; ved støtte på kapasitet til andre virksomheter kreves separate egenerklæringer; ved fellesskap separate egenerklæringer.

  Kilde: Konkurransegrunnlag, pkt. 4.1 Elektronisk egenerklæringsskjema

• Tilbud skal inneholde Bilag 2: Leverandørens løsningsforslag.Kilde: Konkurransegrunnlag, pkt. 3.1 Dokumenter som tilbudet skal inneholde
• Tilbud skal inneholde Bilag 7: Samlet pris og prisbestemmelser.Kilde: Konkurransegrunnlag, pkt. 3.1
• Tilbud skal inneholde elektronisk egenerklæringsskjema (ESPD).Kilde: Konkurransegrunnlag, pkt. 3.1
• Tilbud skal inneholde Bilag A: Tilbudsbrev.Kilde: Konkurransegrunnlag, pkt. 3.1
• Tilbud skal inneholde skjema om egenerklæring om russisk involvering i offentlige anskaffelser.Kilde: Konkurransegrunnlag, pkt. 3.1 + pkt. 2.8 Forbud mot tildeling av kontrakt
• Bilag B: Taushetsbelagte opplysninger (kun hvis relevant).Kilde: Konkurransegrunnlag, pkt. 3.1
• Bilag C: Forpliktelseserklæring (kun hvis relevant, ved støtte på kapasitet fra andre).Kilde: Konkurransegrunnlag, pkt. 3.1
• Bilag D: Forbehold og avvik (kun hvis relevant).Kilde: Konkurransegrunnlag, pkt. 3.1
• Tilbudet skal ha vedståelsesfrist minst 60 dager etter tilbudsfristen.Kilde: Konkurransegrunnlag, pkt. 3.2 Vedståelsesfrist
• Språk for kommunikasjon og tilbudsdokumenter skal være norsk.Kilde: Konkurransegrunnlag, pkt. 3.4 Språk

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

02.10.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Rammeavtale reguleres av SSA-R, faste leveranser av SSA-L og SSA-D, avrop/utviklingsprosjekter av SSA-O og SSA-B (valg av mal avklares med valgt leverandør).Kilde: Konkurransegrunnlag, Kontraktsvilkår
• Krav til lønns- og arbeidsvilkår ved utførelse: leverandøren skal sikre samsvar med forskrift 8. februar 2008 nr. 112 og relevante allmenngjorte tariffavtaler/landsomfattende tariffavtale; leverandør/underleverandører skal dokumentere på forespørsel.Kilde: Konkurransegrunnlag, pkt. 3.6 Krav til lønn og arbeidsforhold under utførelse
• Leverandøren skal rette feil/mangler uten ekstra kostnad.Kilde: Bilag 1 (Kravspesifikasjon), pkt. 3.5 Kapasitet og tilgjengelighet, krav A 5.1
• Leverandøren skal tilby tjenestenivåavtale (SLA) og følge opp statusmøter.Kilde: Bilag 1, krav A 5.2 og A 5.3
• Tjenestenivåavtalen skal minst inneholde angitte elementer (feilhåndtering, sanksjoner/reaksjoner, garantert oppetid, responstid support/til kritiske hendelser, kontaktpunkter og åpningstider, informering om progresjon).Kilde: Bilag 1, krav B 5.1
• Kompetanse-/språkkrav for personell: konsulenter skal ha nødvendig kompetanse; norsk språk i all dialog og dokumentasjon av personells norskkunnskaper (med avgrensede unntak).Kilde: Bilag 1, krav A 4.1 og A 4.2
• GDPR/personvern-by-design: etterlevelse av personvernregler og innebygd personvern (GDPR art. 25) samt databehandleravtale og tilgangsstyring for sensitive data.Kilde: Bilag 1, krav A 1.1 – A 1.4
• Databehandleravtale skal inngås (utkast vedlagt).Kilde: Bilag 1, krav A 1.2
• Integrasjon med kundens eksisterende data/struktur/funksjonalitet skal sikres, og kostnader inngår i prispost 4.Kilde: Bilag 1, krav A 1.7
• Norge digitalt/Geodataloven-etterlevelse og datahenting fra Norge digitalt skal støttes.Kilde: Bilag 1, krav A 2.4
• Betalings- og faktureringskrav: faktura etter utført oppdrag (siste dag i måneden), betalingsfrist minst 30 dager, EHF-faktura.Kilde: Bilag 7, Fakturering

• Dokumentteksten viser ikke selve avropsmekanismen/avropstyper og detaljer om SSA-ramme for avrop utover at avrop på utviklingsprosjekter reguleres av SSA-O/SSA-B.
• Tilbudsdokumentets øvrige tidsfrister (kunngjøringsdato og tilbudsfrist) er oppgitt, men eventuelle leveringskrav i EU-supply utover 'digital postkasse/Altinn' er ikke beskrevet i utdraget.
• Konkurransegrunnlaget nevner at 'Bilag 1 – Kundens kravspesifikasjon' finnes i punkt 3, men innholdet i bilag 1 er ikke fullt gjengitt (utover utdrag av kravtabell).
• Konkrete avvisnings-/sanksjonsvilkår utover henvisning til FOA (f.eks. FOA §24-8) er ikke spesifisert utover 'vesentlige forbehold og avvik'.

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 kravtabellen (A 1.7) står det at «Tilbyders kostnad ved å sikre videre bruk av Fiskeridirektoratet sin eksisterende data, struktur og funksjonalitet … skal inngå som del av Prispost 4 i Bilag 7». Kan dere bekrefte hvordan dere ønsker at dette skal prises i praksis i Prispost 4 (f.eks. engangskostnad for etablering/konvertering/tilpasning, eller også engangskostnader knyttet til vedlikehold av eksisterende funksjonalitet), og om det finnes en forventet leveranse-/arbeidsomfang-liste knyttet til Prispost 4?

   Hvorfor det er verdt å spørre: For å prise riktig må leverandøren forstå hva som faktisk inngår i «sikre videre bruk» og hva som skal legges i engangspost 4 vs øvrige poster.

   Kilde: Bilag 1 punkt 3.1 (A 1.7) og Bilag 7 (Prispost 4)

2. Krav A 2.2 sier at databaseløsningen skal «la seg integrere i Fiskeridirektoratets systemer» og at integreringen skal skje «i et samarbeid mellom valgt leverandør og Fiskeridirektoratet». Hvilke konkrete integrasjonspunkter forventes (f.eks. hvilke eksisterende systemer/applikasjoner, hvilke typer dataflyt, og eventuelle API-/plattformavhengigheter), og hvordan planlegger dere at dere stiller tilgang til grensesnitt/kildesystem (dokumentasjon, testmiljø, tilgang til testdata)?

   Hvorfor det er verdt å spørre: Utydelig omfang og forutsetninger for integrasjon gjør at kostnads- og planrisiko kan bli feil; leverandøren må vite hvilke integrasjoner som faktisk er forventet.

   Kilde: Bilag 1 punkt 3.2 (A 2.2)

3. Krav A 2.3 forutsetter at «kartløsningen skal støtte hendelsesdrevet arkitektur». Kan dere utdype hva dere mener med deres «hendelsesorienterte arkitektur» i praksis (for eksempel hvilke hendelser som skal konsumeres, forventet mønster for publisering/abonnement, bruk av spesifikke meldings-/event-teknologier, samt hvordan dere ønsker at hendelser håndteres ved feil og reprocessing)?

   Hvorfor det er verdt å spørre: For å kunne levere og prise en hendelsesdrevet løsning må leverandøren forstå tekniske forventninger og referansearkitektur.

   Kilde: Bilag 1 punkt 3.2 (A 2.3)

4. Krav A 2.4 sier at dere er part i Norge digitalt, og at leverandørens løsning «skal kunne levere data iht. geodataloven og forpliktelsene i Norge digitalt» og «også kunne hente og bruke data fra Norge digitalt». Hvilke konkrete Norge digitalt-datatyper/tjenester (roller og datakilder) forventer dere at rammeavtalen skal støtte, og finnes det krav til hvilke standarder/profil (f.eks. relevante OGC-tjenester, metadata-krav, tilgangsstyring/autorisasjon) som skal ligge til grunn?

   Hvorfor det er verdt å spørre: Leverandøren må kunne dimensionere arkitektur og integrasjon mot Norge digitalt; manglende presisering kan gi feil tilbud på funksjon og kostnad.

   Kilde: Bilag 1 punkt 3.2 (A 2.4)

5. Krav A 3.2 krever «mulighet for behandling og visning av metadata». Kan dere beskrive hvilke metadata-typer/metadata-modeller dere bruker i dag (f.eks. hvordan metadata opprettes, lagres, hvilke felt/egenskaper som er sentrale, og hvordan metadata skal vises i web/mobile-løsningen)?

   Hvorfor det er verdt å spørre: Metadata kan være alt fra enkle felt til kompliserte katalog-/standardmodeller; uten avklaring blir det vanskelig å levere riktig og prise riktig.

   Kilde: Bilag 1 punkt 3.3 (A 3.2)

6. Krav B 3.9 ber om at web-løsningen skal kunne ha «mulighet for å velge engelsk språk i tillegg til norsk» og at «engelsk innhold og metadata bør kunne opprettes manuelt». Kan dere avklare hva som menes med «metadata» i denne sammenheng (hvilke metadataelementer skal kunne oversettes/vedlikeholdes manuelt), og om dere forventer at oversettelser kan gjøres av dere selv i en administrasjons-/redigeringsflate?

   Hvorfor det er verdt å spørre: Språkstøtte og manuell vedlikeholdsprosess påvirker både løsning og kostnad; leverandøren trenger å forstå hvilke elementer som skal være oversettbare og hvordan.

   Kilde: Bilag 2/Bilag 1 punkt 3.3 (B 3.9)

7. Krav A 4.2 sier at leverandøren skal bruke norsk i all dialog og at tilbudt personell skal dokumentere norsk skriftlig og muntlig. Kan dere presisere om norsk-kravet gjelder alle roller/personer som i praksis kan kontaktes i leveransen (inkl. underleverandørressurser), og om det kan aksepteres dokumentasjon i form av CV/erfaringsbeskrivelse eller trenger dere spesifikke språktest-/sertifiseringsdokumenter?

   Hvorfor det er verdt å spørre: Språkkrav påvirker bemanningsstrategi og underleverandørvalg; leverandøren må vite hva som kan dokumenteres og hvilke personer som omfattes.

   Kilde: Bilag 1 punkt 3.4 (A 4.2)

8. Krav A 5.1 sier at leverandøren skal rette «feil eller mangler» i tilbudt system/tjenester/ansvar uten ekstra kostnad. Kan dere avklare hvordan dere skiller mellom (i) feil/mangler som dekkes av leverandørens standard leveranse, (ii) endringer/forbedringer som følger av nye behov, og (iii) arbeid knyttet til endringer i deres underliggende data/systemer?

   Hvorfor det er verdt å spørre: Uten et klart skille kan leverandøren få uforholdsmessig risiko for «scope creep» som ellers ville vært time- eller utviklingsarbeid.

   Kilde: Bilag 1 punkt 3.5 (A 5.1)

9. Krav A 5.2 og B 5.1 beskriver SLA-innhold, men dokumentet spesifiserer ikke konkrete målverdier (f.eks. oppetid, responstid pr. alvorlighetsgrad, vedlikeholdsvinduer, og sanksjoner/reaksjoner). Kan dere opplyse om dere har forventede minstenivåer eller standard måleparametere for SLA i denne rammeavtalen (og eventuelt hvordan dette skal knyttes til avrop)?

   Hvorfor det er verdt å spørre: For å prise SLA (prispost 3) og utforme bemanning/responshåndtering må leverandøren kjenne minstekrav/måltall eller i det minste forventet nivå.

   Kilde: Bilag 1 punkt 3.5 (A 5.2 og B 5.1) og Bilag 7 (Prispost 3)

10. Tildelingskriteriene (pkt. 5 i konkurransegrunnlaget) er basert på besvarelsene av krav B 1.1–B 3.10 og krav B 4.1–B 4.6 og B 5.1–B 5.3 i Bilag 2. Kan dere beskrive hvordan dere konkret vil vekte/score underpunkter innenfor hvert av disse B-kravene (f.eks. hva som typisk skiller en score 6 fra score 9), og hvordan dere vil håndtere at leverandøren velger å svare med «JA/NEI» men samtidig gi utdyping?

    Hvorfor det er verdt å spørre: Utydelige scoringprinsipper kan føre til feil dokumentasjonsstrategi; leverandøren bør forstå hva som gir uttelling i akkurat disse kriteriene.

    Kilde: Konkurransegrunnlag punkt 5.1–5.2 og Bilag 2 (besvarelse av B-krav)