Statens vegvesen
Anskaffelse av kommunikasjonsløsning for veitrafikksentralene
Statens vegvesen har behov for en felles (nasjonal) kommunikasjonsløsning for vegtrafikksenteralene (VTS)
Formålet med løsningen er å etablere et felles nasjonalt system for telefoni og Nødnett på vegtrafikksentralene (VTS) i Norge. Løsningen skal sørge for effektiv og enkel utførelse av arbeidsoppgavene som trafikkoperatørene utfører i forbindelse med mottak, behandling, logging og viderekobling av samtaler og meldinger.
Del 1: Kjøper
Del 2: Prosedyre
Del 5: Delkontrakt
Del 8: Virksomheter
Kunngjøringsinformasjon
Sammendrag
Anbudsradar
Anskaffelse av en felles (nasjonal) kommunikasjonsløsning for Vegtrafikksentralene (VTS) til telefoni og Nødnett, inkl. etablering, konfigurering, migrering/konvertering av datasett, integrasjon mot HBT (hendelsesbasert toppsystem) og øvrige angitte systemer (bl.a. telefonkatalogtjeneste, 175 samtaler, IP-trunk, SOS-telefoni, mobil fallback, IDM). Konkurransen gjennomføres som konkurranse med forhandling etter forutgående kunngjøring. Det planlegges demonstrasjon og forhandling før tildeling.
Kvalifikasjonskrav
Anbudsradar
- Leverandøren skal ha erfaring fra sammenlignbare oppdrag.
Dokumentasjon: Dokumentasjon skal gis i Vedlegg D – Mal Leverandørens referanser.docx. Besvarelsen skal ha fokus på tilsvarende leveranser.
Kilde: Informasjon og regler om anskaffelsen, pkt. 4.2 Utvelgelseskriterier (NR 1) - Leverandøren skal ha tilstrekkelig kapasitet til å gjennomføre kontrakten.
Dokumentasjon: Dokumentasjon skal gis i Vedlegg F – Mal kapasitet.docx.
Kilde: Informasjon og regler om anskaffelsen, pkt. 4.2 Utvelgelseskriterier (NR 2)
Krav til tilbudet
Anbudsradar
- Signert søknadsbrev for kvalifisering.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Kvalifikasjon)
- Utfylt ESPD-skjema i KGV (husk eget ESPD-skjema for eventuelle underleverandører).Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Kvalifikasjon)
- Eventuell(e) forpliktelseserklæring(er) fra annen virksomhet (kun hvis leverandøren støtter seg på kapasiteten til annen virksomhet) samt separate egenerklæringer for disse.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Kvalifikasjon)
- Utfylt Vedlegg D – Mal Leverandørens referanser (jfr. kvalifikasjonskriterier pkt. 4.2 punkt 1).Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Kvalifikasjon)
- Utfylt Vedlegg F – Mal Kapasitet (jfr. pkt. 4.2 punkt 2).Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Kvalifikasjon)
- Signert tilbudsbrev.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 2 (SSA-T og SSA-V): Leverandørens løsningsspesifikasjon (inkl. kundens kravspesifikasjon bilag 1 og vedlegg 1.1–1.3).Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 4 (SSA-T og SSA-V): Prosjekt- og fremdriftsplan, Detaljspesifikasjon, Dokumentasjon og Opplæring.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 5 (SSA-T): Testing og godkjenning.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 5 (SSA-V): Tjenestenivå med standardiserte kompensasjoner.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 6 (SSA-T og SSA-V): Administrative bestemmelser.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 7 (SSA-T og SSA-V): Samlet pris og prisbestemmelser.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 9 (SSA-V): Vedlikeholdsavtaler med tredjepart.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 10 (SSA-T og SSA-V): Lisensbetingelser for standardprogramvare og fri programvare.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Utfylt bilag 11 (SSA-V): Databehandleravtale (for valgt leverandør).Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Sladdet utgave av tilbudet.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Evt. tilgang til demobrukere.Kilde: Informasjon og regler om anskaffelsen, SJEKKLISTE (Tilbud)
- Deltakere til tilbyderkonferanse: sende deltagere med fullt navn og e-post via meldingsfunksjonen i KGV.Kilde: Informasjon og regler om anskaffelsen, Tilbudskonferanse
Innleveringsvilkår fra kunngjøringen
- Frist for forespørsel/tilbud
- 24.09.2026
- Språk
- English, norsk
- Elektronisk katalog
- Ikke tillatt
Tildelingskriterier
Anbudsradar
| Kriterium | Vekt | Beskrivelse |
|---|---|---|
| Pris | 30 % | Pris |
| Kvalitet | 70 % | Kvalitet |
| Kvalitet – unntak fra klima- og miljøkrav i norsk anskaffelsesregelverk: Anskaffelsen har uvesentlig klimaavtrykk og miljøbelastning (skal begrunnes) | 0 % | I denne anskaffelsen er tildelingskriteriet for miljø ikke vektet med 30 %. Dette er i tråd med unntaksbestemmelsen i FOA § 7-9 femte ledd. Begrunnelsen er at anskaffelsen gjelder etablering av en digital løsning som skal driftes av internt i Kundens miljøer, og som har et klimaavtrykk og en miljøbelastning som anses som uvesentlig. Selve løsningen er ikke fysisk og medfører ingen vesentlig ressursbruk utover normal IT-infrastruktur. Det er derfor ikke hensiktsmessig å fastsette egne miljøkriterier for tildeling. |
Viktige kontraktskrav
Anbudsradar
- Kontraktsperiode: 3 år fra kontraktsinngåelse, med opsjon forlengelse 1+1+1+1+1+1+1 (totalt 10 år).Kilde: Informasjon og regler om anskaffelsen, Kontraktsperiode, pkt. 2.2
- Kontraktsforhold reguleres av SSA-T og SSA-V med tilhørende bilag.Kilde: Informasjon og regler om anskaffelsen, Kontrakttype, pkt. 2.1
- Ingen adgang til deltilbud eller alternative tilbud.Kilde: Informasjon og regler om anskaffelsen, pkt. 3.4 og 3.5
- Ved vesentlige avvik fra anskaffelsesdokumentene kan tilbud avvises; avvik skal være presise og entydige og henvises i tilbudsbrevet (sidetall/punktnummer).Kilde: Informasjon og regler om anskaffelsen, pkt. 5.1 Avvik
- Leverandøren må vedstå tilbudet i minimum 120 dager etter tilbudsfrist (kan forlenges av kunden).Kilde: Informasjon og regler om anskaffelsen, Frister
- Godkjenning/akseptansetest og godkjenningsperiode: akseptansetest og godkjenningsperiode reguleres i SSA-T (fasene) og bilag 5/4; godkjenningsperiode er 3 måneder fra ordinær drift dersom ikke annet er avtalt.Kilde: SSA-T avtaletekst, kap. 2.6–2.7 (særlig 2.7.1) og kap. 2.6/2.6.10 i utdraget
Forbehold ved utdraget
Anbudsradar
- Krav til kvalifikasjonsforespørsler (minstekrav utover referanse/kapsitet) er ikke synlig i utdraget; det oppgis at kravene angis i sin helhet i KGV-løsningen.
- Tilbuds- og dokumentasjonskrav knyttet til frister for innlevering av tilbud/kvalifikasjonsforespørsler er vist som dato i fremdriftsplan, men eksakte KGV/Doffin/TED-frister for hvert steg er ikke gjengitt.
- Funksjonelle/ikke-funksjonelle/sikkerhets- og personvernkrav detaljer ligger i Vedlegg 1.1–1.3 (xlsx), men disse er ikke inkludert i teksten, så konkrete kravpunkter er ikke trukket ut.
- Prisberegningsgrunnlag refereres til Bilag 7 og punkter i SSA-T/SSA-V, men selve beregningsoppskriften og beløpsparametere er ikke gjengitt i utdraget.
- Kontrakts-/utførelseskrav utover SSA-T generiske bestemmelser (f.eks. SSA-V spesifikke tjenestenivåkrav) er ikke hentet, siden SSA-V-tekst/bilag ikke er inkludert.
Verdt å avklare med oppdragsgiver
Anbudsradar
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.
I bilag 1 «Kapasitet på telefoni» er det angitt 1 trunk per linje (SOS DC X/Y, DC X/Y og IVR1/IVR2) og at det skal være redundans mellom disse. Kan oppdragsgiver presisere hvordan redundansen skal utformes i praksis (f.eks. aktiv-passiv vs. aktiv-aktiv), og om det finnes eksplisitte minimumskrav til failover-tid eller failover-scenarioer som må ligge til grunn for leverandørens løsning og testing?
Hvorfor det er verdt å spørre: Redundans- og failoverkrav påvirker arkitektur, kost og testoppsett, og bør avklares før tilbud for å redusere risiko for avvik ved akseptansetest.
Kilde: Bilag 1: Avtalens omfang / Kapasitet på telefoniI bilag 1 «Kapasitet på Nødnett» står det «Kommunikasjonsløsningen skal imidlertid ikke allokere ressurser/lisenser før operatør aktiverer seg på en talegruppe» og at en operatør kan logge på egne regioners talegrupper i tillegg til felles. Kan oppdragsgiver bekrefte hvordan dette skal forstås (hvilke «ressurser/lisenser» gjelder: API-sesjoner, talkgroup-allokering, eventuelle DCS/IMW-tilganger, osv.), og om det er definert mål/KPI for respons ved aktivering (f.eks. tid til tilgjengelig talegruppe) som bør planlegges og testes?
Hvorfor det er verdt å spørre: Fortolkning av «allokere ressurser/lisenser» kan gi vesentlige utslag i design og i hvor mye funksjonalitet som må være aktiv umiddelbart ved pålogging/aktivering.
Kilde: Bilag 1: Avtalens omfang / Kapasitet på NødnettI bilag 4 «Prosjekt- og fremdriftsplan» er det angitt at «Avtalen … senest 15.desember 2027» er avgjørende for driftsattakelse for alle VTSer, og at avvik gir dagbøter iht. SSA-T pkt. 9.5.3 (dagbotbelagte frister). Kan oppdragsgiver utdype hvilke milepæler som faktisk er «dagbotbelagte» (liste over hvilke milepæler som trigges), samt foreslå hvilke avhengigheter fra oppdragsgiver (f.eks. godkjenning av detaljspesifikasjon, tilgjengelighet av testmiljø/ressurser, typegodkjenning/DSB-aktiviteter) som særlig bør legges inn for å unngå dagbøter?
Hvorfor det er verdt å spørre: Dagbøter knyttes til spesifikke frister/milepæler, og leverandøren må kunne prise og planlegge realistisk for å unngå uforutsett økonomisk risiko.
Kilde: Bilag 4: Prosjekt- og fremdriftsplan / Dagbot ved forsinkelseI bilag 4 er det krav om at detaljspesifikasjonen og fullstendig prosjektplan skal leveres innen fristene «som er fastsatt her», men selve datofeltene er ikke utfylt i utdraget. Kan oppdragsgiver bekrefte eksakte datoer/frister for: (1) endelig godkjenning av detaljspesifikasjon, (2) overlevering av endelig versjon av overordnet/funksjonell spesifikasjon og skjermbilde-/rapport-layout, og (3) evt. kundens beslutningsfrister hvis de er annerledes enn avtalen?
Hvorfor det er verdt å spørre: Ulike frister påvirker planlegging, bemanning og leveranser til integrasjoner samt risiko for forsinkelser/dagbøter.
Kilde: Bilag 4: Levering og godkjenning av detaljspesifikasjonen / Frister for godkjenningI bilag 7 «Samlet pris og prisbestemmelser» og leveranselisten (L5/L11 m.fl.) er integrasjonene oppgitt som «Fastpris» eller med estimert timeforbruk (f.eks. IDM/HBT/Telefonkatalog/SOS/Nødnett/175/IP-trunk/Mobil fallback). For å sikre sammenlignbar og korrekt prising: Kan oppdragsgiver bekrefte hva som inngår i «Fastpris»-postene (særlig: antall testiterasjoner, nødvendig dokumentasjon, konfigurering i ATM/PROD, og eventuelle avklaringer/oppgraderinger som følge av endrede/oppdagede grensesnitt i spesifiseringsfasen)?
Hvorfor det er verdt å spørre: Hva som faktisk er «inkludert» i fastprispostene bestemmer tilbudt risiko og kost, og bør avklares før tilbudsinnlevering.
Kilde: Bilag 7: Samlet vederlag frem til endelig godkjenning - leveringsdag / L1–L13I bilag 1 «Leveranser frem til leveringsdag» beskrives integrasjon HBT via ActiveMQ og at HBT «også benytter et API som kommunikasjonsløsningen eksponerer». Kan oppdragsgiver spesifisere hvilket ansvar leverandøren har for denne «eksponeringen» (f.eks. API-endepunkter, auth/tokens, datamodell for innhenting av påloggede brukere), og hvilke detaljer som finnes i «Funksjonelle krav 1.6.1, 1.6.3, 2.8.1 og 10.1.11» (herunder om det finnes spesifisert kontrakt/format som må oppfylles)?
Hvorfor det er verdt å spørre: Integrasjonsansvaret (eksponert API) kan være den mest risikofylte delen og påvirker både utvikling og akseptansekriterier.
Kilde: Bilag 1: Leveranser frem til leveringsdag / L5 Integrasjon HBTVedrørende integrasjon Nødnett: konkurransegrunnlaget viser til Motorola Application Developer Program og en «Nødnett Interface for line connected control rooms». Kan oppdragsgiver bekrefte om leverandøren skal gjennomføre DSBs typegodkjenning som en del av leveransen/kontraktsrisiko (og i tilfelle: hvem er «supplier of the control room solution» i denne sammenheng), samt hvordan typemodning/oppgraderinger (major vs minor release) skal håndteres innen leveransefristen 15.12.2027?
Hvorfor det er verdt å spørre: Typegodkjenning kan være en tidskritisk og prosessstyrt aktivitet med krav til dokumentasjon og test i DSB/Motorola-miljø som må inn i prosjektplan og risikobilde.
Kilde: Bilag 1: Leveranser frem til leveringsdag / L8 Integrasjon Nødnett; samt Bilag 1/SSA-T henvisninger til Nødnett sikkerhetskravI bilag 1 (Samtaleruting og kategorisering – Vedlegg B) beskrives kategorier/prioritet, svarprofiler og at systemet bør ha mekanismer for å sende samtaler videre når en kategori er ubemannet. Kan oppdragsgiver bekrefte hvilke «overflytingsregler» som skal gjelde når en kategori er ubemannet (f.eks. prioritert liste over alternativ kategori/operatør, krav til minsteventetid, og om det forventes egne regler for «SOS-telefon»)?
Hvorfor det er verdt å spørre: Ruting ved ubemannet kategori påvirker både brukerflyt, algoritme og testbarhet; uklare regler kan gi avvik i akseptansetest.
Kilde: Vedlegg B: Ruting / Lokal telefoni / SOS-telefon / KonfigurasjonI bilag 5 «Testing og godkjenning» er det beskrevet inngangskriterier til akseptansetest (0 åpne A-feil, <=2 åpne B-feil, <=5 åpne C-feil med plan, osv.). Kan oppdragsgiver avklare hvordan «åpne feil» skal klassifiseres og kommuniseres (hvem bestemmer A/B/C/D, og hva er beslutningsprosessen ved uenighet om feilkategori), samt om det finnes et avtalt format for feilrapportering/testrapporter som leverandøren må følge?
Hvorfor det er verdt å spørre: Ulike tolkninger av feilklassifisering og rapporteringsformat kan skape uenighet og forsinkelser rett før akseptansetest starter.
Kilde: Bilag 5: Forberedelser til akseptansetest / Inngangskriterier til akseptansetestenI bilag 2 står at leverandøren fyller ut løsning «med avvik, forbehold og andre endringer» som kan medføre avvisning. Kan oppdragsgiver beskrive hvordan dere vurderer avvik i praksis: (1) hvordan skal henvisning i bilag 2 gjøres for at det skal anses som «besvart», (2) om det er terskel for «avvik» vs. «beskrivelse av alternativ», og (3) om dere har et eksempel på akseptabel respons for typiske krav i vedlegg 1.1–1.3?
Hvorfor det er verdt å spørre: Tydelig avviks- og besvarelseslogikk reduserer risiko for avvisning og sikrer korrekt innsending av bilag 2.
Kilde: Bilag 2: Leverandørens løsningsbeskrivelse / Besvarelse av funksjonelle-, ikke-funksjonelle- og sikkerhetskrav; samt innledende tekst om avvik og avvisning
Kurs og rådgivning fra redaksjonen
Gratis fagmøte – 30 minutter digitalt om aktuelle anskaffelsestemaer.
Se datoer →Kurs: Hvordan vinne anbud – praktisk kurs for deg som skriver tilbud.
Les mer →Rådgivning
Ta kontakt →