Veileder for anskaffelse av konkurransegjennomføringsverktøy (KGV)

Om veilederen og innhold

Veilederen er laget for offentlige oppdragsgivere som skal anskaffe KGV for å understøtte sine anskaffelser omfattet av Forskrift 12. august 2016 nr. 974 om offentlige anskaffelser. Dokumentet er omfattende og det er ikke meningen at alle skal lese det fra A-Å, men heller bruke innholdsfortegnelsen til høyre til å hoppe til relevante avsnitt, eller søke ved bruk av for eksempel Ctrl+F.

Veilederen inkluderer et forslag til kravspesifikasjon. Denne inneholder krav DFØ mener dekker de fleste oppdragsgiveres behov, men kan også brukes som et utgangspunkt dere kan tilpasse videre. Det er ikke meningen at kravspesifikasjonen skal kopieres og brukes ukritisk i sin helhet. Oppdragsgiver må vurdere om forslaget til kravspesifikasjon er tilstrekkelig til å dekke behovene i deres virksomhet.

Kravene til elektronisk kommunikasjon er like for alle forskriftene som følger av Lov 17. juni 2016 nr. 73 om offentlige anskaffelser, men veilederen tar ikke for seg særkrav knyttet til anskaffelser i forsynings-, konsesjons, eller forsvarssektoren. Vi håper likevel den kan brukes som et utgangspunkt også for disse sektorene.

Denne versjonen dekker kjøp av KGV til konkurransefasen og omtaler i liten grad anskaffelse av verktøy til bruk i kontraktsoppfølgingsfasen (KAV). KAV er et tema vi vil skrive mer om i en senere versjon.

Veilederen vil ikke ta for seg generell anskaffelsesfaglig veiledning. Dette finnes allerede på anskaffelser.no. Vi begrenser oss til temaer som er relevante og spesifikke for anskaffelse av KGV, men lenker til relevant anskaffelsesfaglig informasjon underveis.

Avklare behov

Et standard KGV vil være tilstrekkelig for å dekke behovet for prosess-støtte for de fleste offentlige virksomheter. I tillegg til å ivareta lovens minimumskrav, vil standard KGV bidra til å effektivisere gjennomføringen av anskaffelsene, sikre at all relevant informasjon blir lagret trygt og gi grunnlag for uthenting av statistikk.

Virksomheter med få anskaffelser per år kan vurdere om det er mer kostnadseffektivt å gå sammen med andre om anskaffelse av KGV, for eksempel gjennom et innkjøpssamarbeid. Større virksomheter vil kunne ha mer spesialiserte behov, og bør vurdere å stille krav til funksjonalitet utover det standardløsningen dekker, for eksempel til flere automatiserte arbeidsprosesser. Desto flere arbeidsprosesser som automatiseres, desto større blir effektiviseringsgevinsten for virksomheten. Oppdragsgivere må også være bevisst på at å etterspørre ny funksjonalitet bidrar til innovasjon på KGV-området.

Oppdragsgiver bør vurdere krav om integrasjon med øvrige sentrale IKT-systemer i virksomheten, som for eksempel økonomisystem. Vær imidlertid oppmerksom på at individuelle tilpasninger og integrasjoner kan være svært kostnadsdrivende og binder virksomhetene til tjenesteleverandører. Standardløsninger og -integrasjoner er mer kostnadseffektive.

Det er en rekke momenter som avgjør hvilket behov dere skal dekke gjennom anskaffelsen, for eksempel kan virksomhetens IKT-strategi stille krav til den tekniske løsningen, herunder valg av skyløsning eller lokal server. Dersom virksomheten ikke har helt særskilte sikkerhetskrav som tilsier at løsningen bør være installert i virksomhetens eget driftsmiljø, anbefales det at standard KGV kjøpes som en skytjeneste som leveres over nett, også kalt Software as a Service (SaaS). Se mer om å anskaffe skytjenester.

De fleste virksomheter har allerede brukt KGV i noen år, og som for andre anskaffelser er det hensiktsmessig å gjennomføre aktiviteter for å fange opp behovene og erfaringene til de interne brukerne av tjenesten, slik at mangler fra forrige anskaffelse blir dekket.

Kontraktsstrategi og vurdering av markedet

Oppdragsgivere bør foreta en første vurdering av markedet via nett, men per høsten 2021 er konkurransen i det norske KGV-markedet liten. Markedssituasjonen i Norge har endret seg i løpet av kort tid og det er for tiden kun én aktiv leverandør av KGV; Mercell. Mercell har kjøpt opp flere av sine konkurrenter både i det norske markedet og i Europa, blant annet EU-Supply CTM, Visma TendSign, Aksess Innkjøp, Opic, Cloudia, Comcare og Innovasion. Mercell bygger en ny og konsolidert løsning, men frem til denne er klar vil del fortsette å drifte flere av sine løsninger i det norske markedet.

Det finnes andre aktører som vurderer å utvikle et KGV for norske offentlige anskaffelser, og det er europeiske aktører som vurderer å gå inn i det norske markedet. DFØs vurdering er at nye aktører vil lansere KGV innen overskuelig fremtid og oppdragsgivere anbefales å følge med på markedssituasjonen. Snakk gjerne med nettverket ditt, del erfaringer og diskuter mulige alternativer.

Dette betyr at oppdragsgivere for tiden har følgende alternativer:

• Forlenge nåværende avtale eller utløse opsjoner. DFØ forlenget sin avtale om KGV med ett år, fra juni 2022 til juni 2023, med hjemmel i FOA § 28-1 bokstav d. Her fremgår det at kontrakten kan endres dersom flere vilkår er oppfylt, herunder at det foreligger omstendigheter som en en aktsom oppdragsgiver ikke kunne forutse. Oppdragsgiver må foreta en konkret vurdering. Les mer i Regjeringens veileder om endring i eksisterende kontrakt.
• Inngå ny avtale med en kortere avtaleperiode, eller flere opsjoner for å ivareta fleksibilitet. En kortere avtaleperiode kan påvirke pris negativt og krever ny anskaffelse kortere frem i tid. Fordelen med dette alternativet er fleksibiliteten.
• Tilpasse anskaffelsen og kunngjøringsteksten på TED, slik at utenlandske leverandører kan gi tilbud. Merk at norske kunngjøringer må være på norsk og kunngjøres via Doffin, jfr. FOA kapittel 21. Leverandøren av KGV må dermed både ha støtte for norsk i kunngjøringene og integrasjon mot Doffin, men det er ikke ulovlig å bruke et KGV som hovedsakelig er på et annet språk. Island har for eksempel ikke KGV på islandsk, men på engelsk.
• Inngå ny avtale med vanlig avtalelengde, eventuelt med noe mer fleksibilitet til å avslutte avtalen tidligere. Dersom det er få eller kun én leverandør kan dere vurdere å forhandle. For anskaffelser over EØS-terskelverdi følger muligheten for forhandling av jfr. FOA § 13-2 .
• Gjennomføre en konkurransepreget dialog eller publisere konkurranse om innovasjonspartnerskap,  for å utvikle hel eller delvis KGV-funksjonalitet, for eksempel innebygget arkiv-funksjonalitet. Både DFØ og andre aktører kan være aktuelle samarbeids- eller sparringspartnere i en slik prosess.
• Foreta en direkteanskaffelse etter FOA § 5-2 gjennom en intensjonskunngjøring, jfr. FOA §§ 8-18. FOA § 5-2 er en unntaksbestemmelse og oppdragsgiver må foreta en konkret vurdering av om vilkårene er oppfylt. Les mer i Regjeringens veileder. Dersom anskaffelsen følger FOA del III er adgangen snevrere og  vilkårene i § 13-4(1) bokstav a) må være oppfylt, jfr. § 13-3. Muligheten for å gjøre en intensjonskunngjøring for anskaffelser over EØS-terskelverdi fremgår av FOA § 21-5.

Dialog med markedet

I planleggingen av anskaffelsen, og før konkurransen gjennomføres, kan det være nyttig med dialog med ulike aktører og relevante fagmiljøer. Dette gjelder særlig når det er et uoversiktlig eller begrenset marked, slik som for KGV.

Oppdragsgivere som ønsker å gjennomføre markedsundersøkelser, kan benytte en veiledende kunngjøring til dette formålet. En veiledende kunngjøring som er brukt for å invitere til dialog forplikter ikke oppdragsgiveren til senere å kunngjøre en konkurranse. Istedenfor å publisere den veiledende kunngjøringen i Doffin og TED-databasen, kan den publiseres på oppdragsgivers kjøperprofil, jfr. FOA § 21-4.

Formålet med en veiledende kunngjøring er å informere tidlig om og forberede markedet på kommende konkurranser. Oppdragsgiveren kan ikke kunngjøre en konkurranse ved bruk av en veiledende kunngjøring, men siden markedet har fått et forvarsel kan tilbudsfristen kortes ned ved en etterfølgende alminnelig kunngjøring.

Andre aktuelle problemstillinger å ta opp i en markedsdialog kan være:

• Informasjon om oppdragsgivers behov
• Vurderinger knyttet til gevinster og kostnader i helhetlig sammenheng og lengre perspektiv
• Hva finnes tilgjengelig i markedet av ulike tjenestetilbud og alternative måter å løse behovene på
• Innsyn i tjenesteutøvelse: Innspill fra leverandører om deres vurdering av tjenestens kvalitet, endringer i brukers behov og kostnader
• Innspill om forhold som har stor betydning for kvalitet og pris ved en fremtidig anskaffelse
• Innspill om hva som kan være hensiktsmessige kvalitetsindikatorer og måle- og rapporteringsrutiner (SLA) i kontraktsfasen
• Hvordan gi rom for å implementere nye løsninger/justeringer gjennom kontraktsperioden?
• Eventuelt å avdekke behov for å utvikle nye løsninger gjennom et forsknings- og utviklingsprosjekt, for eksempel innebygget arkiv eller økt grad av automatisering i KGV.

Det er lov å ha dialog med markedet så lenge du behandler leverandørene likt, unngår å gi urimelig konkurransefordel og ikke røper forretningshemmeligheter. Det er flere måter å gjennomføre dialogaktiviteter på. Se veiledning om dialog med markedet.

Oppdeling av anskaffelsen

Denne versjonen av veilederen tar ikke for seg kjøp av et kontraktsadministrasjonsverktøy (KAV), men oppdragsgiver bør likevel vurdere om dere ønsker å kjøpe KAV i tillegg til KGV. På grunn av dagens situasjon med et begrenset leverandørmarked anbefaler vi at dere vurderer å dele opp en slik anskaffelse, slik at leverandører kan gi tilbud på KGV eller KAV enkeltvis.

Risikovurdering ved anskaffelse av skytjenester

Veilederen tar utgangspunkt i at KGV er en skytjeneste (software-as-a-service), og det er viktig å stille tilstrekkelige krav til informasjonssikkerhet. DFØ anbefaler at oppdragsgiver foretar en risikovurdering, eller ROS-analyse (risiko og sårbarhetsanalyse). Denne risikovurderingen danner grunnlag for kravene til sikkerhet som skal inn i konkurransegrunnlaget. Du vil finne mer konkret veiledning om ROS-analyser for skytjenester på DFØs markedsplass for skytjenester.

I forslaget til kravspesifikasjon, kategori 6.b. Informasjonssikkerhet, finner du en rekke generiske krav på dette området. Disse er utformet på bakgrunn av en generell ROS-analyse DFØ har gjennomført for KGV-systemer. Du må selv vurdere om disse kravene er tilstrekkelige og riktige for din virksomhet. Dersom virksomheten har spesielle behov med tanke på sikkerhet, kan det være en løsning å ha en åpen dialog med leverandørmarkedet rundt hvordan disse behovene kan løses. Da sikrer du deg mot å stille krav som ingen av leverandørene kan innfri, eller at du stiller unødvendig strenge krav til sikkerhet. Les om dialog med markedet ovenfor.

Valg av anskaffelsesprosedyre

Mange oppdragsgivere bruker åpen anbudskonkurranse ved kjøp av KGV når anskaffelsen er over EØS- terskelverdi. Ved kjøp av standard KGV kan denne anskaffelsesprosedyren fungere godt. Oppdragsgiver må alltid vurdere anskaffelsesprosedyre opp mot hvilke behov KGV skal oppfylle, samt anskaffelsens verdi. Dersom dere har behov som ikke dekkes i markedet i dag, bør dere vurdere en annen anskaffelsesprosedyre. Les om andre alternativer under overskriften vurdering av markedet og markedsdialog. Se også generell veiledning om valg av prosedyre. I tillegg kan veilederen om kjøp av skytjenester være nyttig.

Avtalevalg

Så lenge KGV kjøpes som standard hyllevare (SaaS) inkludert drift og vedlikehold, vil det være mest aktuelt å bruke tjenesteavtalen (SSA-L). Veiledningen tar utgangspunkt i bruk av denne. SSA-L kan også inkludere noe tilpasning og konfigurering dersom oppdragsgiver beskriver dette på forhånd. Er du usikker på om funksjonaliteten du behøver regnes som standard eller må utvikles spesielt, kan du ha en dialog med leverandørmarkedet. For de som ønsker at KGV-løsningen skal utvikles eller tilpasses (og der kunden ikke på forhånd kan spesifisere nøyaktig hvordan programvaren skal utvikles/tilpasses), og du har behov for leverandørens ekspertise, vil SSA-T/SSA-sky være bedre egnet. For mer informasjon om SSA og hjelp til å velge riktig avtale se statens standardavtaler.

Prismodell og avtaleperiode

Et KGV har vanligvis tre hovedtyper kostnader:

• Kostnader knyttet til implementering. Dette vil typisk være nødvendig tilpasning til kundens øvrige løsninger, grunnopplæring og tilpasning til virksomhetsspesifikke maler og arbeidsflyt.
• Brukskostnader er den årlige kostnaden virksomheten har for å ha tilgang til en fungerende og oppdatert KGV-løsning. Kostnaden omfatter løpende drift og alle oppgraderinger leverandøren inkluderer i sin standardløsning.  Det vanligste er at markedet tilbyr ulike brukerlisenser til en årlig kostnad. Virksomhetens behov for de ulike lisenstypene vil da være avgjørende for den årlige totale kostnaden. Enkelte leverandører kan tilby en generisk pakkeløsning for hele virksomheten, såkalt ELA (Enterprise License Agreement). For store virksomheter med innkjøp organisert mange steder kan dette være en alternativ prismodell.
• Den siste gruppen kostnader er knyttet til videreutvikling av løsningen som er initiert eller bestilt av din virksomhet. Avhengig av hvor godt beskrevet bestillingen er, og dermed enklere å estimere, vil dette enten bli ved fastpris eller med løpende konsulenttimer.

De fleste KGV-leverandører opererer ikke med åpne priser/prismodeller på nettsidene sine, slik som for eksempel Microsoft og andre leverandører av programvare rettet mot massemarkedet. For at leverandøren skal kunne gi et best mulig tilbud, må du beskrive din virksomhets behov og organisering av innkjøpsvirksomheten godt, og la leverandøren komme med sitt pristilbud. Det kan også være lurt å snakke med andre som nylig har kjøpt KGV.

SSA-L gir i utgangspunktet en avtaleperiode på 3 år med mulighet for forlengelse med ett år av gangen. Det er flere forhold som påvirker hvilken avtaleperiode dere bør velge:

• Planlagte endringer i organisatoriske forhold (for eksempel inngåelse i innkjøpssamarbeid, mulig sammenslåing eller lignende). En løsning kan være å legge inn mulige opsjoner i avtaleperioden.
• Forventet markedsutvikling, både i antallet leverandører og funksjonelt omfang i den enkelte løsning. Det vil trolig komme flere leverandører på markedet de neste årene.
• Hvilke andre systemer er KGV-løsningen integrert mot, og hvor enkelt det er å bytte ut integrasjonen. En kompleks og tett integrasjon kan være et argument for en lengre kontraktsperiode. Samtidig bør man så langt det er mulig, unngå integrasjoner som er kostbare og tidkrevende å bytte, og som fører til lock-in.

Spesifikasjon, krav og kriterier i konkurransen

Forslag til kravspesifikasjon tar for seg krav og kriterier som knytter seg til KGV-tjenesten. Kvalifikasjonskrav, altså krav som knytter seg til forhold ved leverandøren, omtales ikke, men du kan lese mer om kvalifikasjonskrav og dokumentasjon under anskaffelsesprosessen.

Med krav mener vi minimumskrav eller absolutte krav til KGV som er listet opp i en kravspesifikasjon. I forslaget til kravspesifikasjon er disse markert med en S for «skal-krav». Dersom KGV-løsningen ikke oppfyller skal-kravene vil dette medføre avvisning fra konkurransen. For å være lovlige må kravene ha tilknytning til leveransen og stå i forhold til anskaffelsens formål og verdi, jfr. FOA §§ 8-5 og 15-1. Les mer om kravspesifikasjon på regjeringen.no.

Med kriterier mener vi tildelingskriterier som oppdragsgiver evaluerer tilbudt KGV på, jfr. FOA §§ 8-11 og kapittel 18. Leverandøren som har levert det tilbudet som etter oppdragsgivers vurdering scorer best på disse kriteriene, skal tildeles kontrakten. Kriteriene skal være objektive og saklige og i samsvar med de grunnleggende prinsippene. I forslaget til kravspesifikasjon er disse markert med en B for «bør-krav».

I kravspesifikasjoner for IT-løsninger som KGV er det krevende å vurdere hva som skal spesifiseres i detalj og hva som heller bør ytelses- og funksjonsspesifiseres (også kalt åpen spesifikasjon). Ved sistnevnte beskriver oppdragsgiver sitt behov på en åpen måte slik at leverandør kan komme med sitt løsningsalternativ. I denne veilederen legges det opp til en kombinasjon av detaljerte krav og ytelses- og funksjonskrav. Mer åpne krav og kriterier, istedenfor detaljerte, spesifikke og absolutte krav bidrar til økt konkurranse i et lite marked, og forhindrer at leverandører blir unødvendig avvist fra konkurransen. Vær oppmerksom på at dersom dere stiller strenge krav til funksjonalitet og i stor grad detaljerer hva slags løsning dere ønsker, vil dette kunne hemme konkurransen og redusere antall tilbud dere mottar. Les mer om tildelingskriterier under anskaffelsesprosessen og Regjeringens veileder punkt 11.9.

Tildeling kan gjøres på grunnlag av tre alternativer, jfr. FOA § 18-1:

1. Laveste pris
2. Laveste kostnad
3. Beste forholdet mellom pris eller kostnad eller kvalitet

For anskaffelse av KGV anbefaler DFØ å ta hensyn til nr. 3, kvalitet.

Tabellen foreslår en rekke underkriterier kvalitet og pris/kostnad kan deles opp i. Oppdragsgiver må vurdere hvilke som er mest hensiktsmessig ut fra virksomhetens behov, men det anbefales å ikke ha for mange underkriterier for å evaluere bør-kravene.

Kriterium	Krav til dokumentasjon
Kvalitet Under dette kriteriet vurderes: - Løsningens brukervennlighet - Grad av digital støtte - Grad av strukturert informasjon - Grad av gjenbruk av data - Effektivisering av kundens arbeidsprosesser i en anskaffelse - Fleksibilitet og mulighet for rapporter og/eller statistikk - Tilbudt tjenestenivå, herunder rutiner for vedlikehold og feilretting	- Besvarte krav merket med "Bør" i vedlegg 1 til bilag 1 i SSA-L - Tilbudt tjenestenivåavtale (SLA)
Pris/kostnad Under dette kriteriet vurderes: - Tilbudt pris for løsningen - Livssykluskostnader, herunder prismodell for nye moduler og tillegg til løsningen	- Ferdig utfylt prisskjema - Veikart for videreutvikling av løsningen og nye moduler som planlegges

Oppdragsgiver må huske på at dersom det blir mange tildelingskriterier, blir evalueringen tilsvarende mer komplisert. Tildelingskriterier av relativt sett liten betydning kan da få uforholdsmessig stor påvirkning på sluttresultatet av evalueringen. Mange tildelingskriterier som utjevner forskjellen mellom de tilbudte løsningen kan medføre at det kun er pris som vil skille de ulike tilbudene fra hverandre. Vi anbefaler at oppdragsgiver tester ut evalueringen før kunngjøring, både for å se hvordan evalueringen lar seg gjennomføre og for å sikre at tildelingskriteriene slår ut riktig i evalueringen. Les mer om detaljert beskrivelse av evalueringsmodeller under anskaffelsesprosessen.

Oppdragsgiver bør ikke kopiere kravspesifikasjonen uten å vurdere hva som er nyttig og relevant for din(e) virksomhet(er). Kravspesifikasjonen må sees på som innspill og tips.

Kontraktskrav

Det er planlagt endringer på anskaffelsesområdet, både i regelverket og som følge av digitalisering, og det kan det være en fordel å stille enkelte krav som kontraktskrav istedenfor krav som må være oppfylt på anskaffelsestidspunktet. Da unngår dere å avvise leverandører som ikke har utviklet ny funksjonalitet enda.

Forslaget til kravspesifikasjon inneholder et krav til utvikling som sikrer at oppdragsgiver får nytte av at tjenesten videreutvikles. Leverandøren skal i dokumentasjon av kravet beskrive veikartet sitt for tjenesten, og dere kan her fange opp funksjonalitet som kan bli tilgjengelig i kontraktsperioden. Dersom dere ønsker å stille krav til når leverandøren skal ha på plass endringene i sin løsning kan dere ta med klausuler om dette i kontrakten.

Generelle minimumskrav til KGV

Til tross for fremtidige endringer på anskaffelsesområdet og markedssituasjonen for KGV, er det enkelte absolutte krav oppdragsgiver likevel bør stille til KGV, enten som følge av regelverk, eller fordi det er nødvendig for å sikre effektive digitale anskaffelser.
I forslaget til kravspesifikasjon er kravene som behandles nedenfor markert som «Skal»-krav. Disse minimumskravene anbefaler vi å stille som absolutte krav.

Samsvar med gjeldende regelverk

Det er viktig å kreve at løsningen til enhver tid har funksjonalitet i samsvar med krav i gjeldende regelverk på anskaffelsesområdet og andre områder med regelverk offentlige virksomheter må forholde seg til.

Hovedregelen i anskaffelsesforskriften kapittel 22 er at all kommunikasjon og informasjonsutveksling mellom oppdragsgiver og leverandørene skal skje skriftlig ved bruk av elektroniske kommunikasjonsmidler, se krav 2.c.9. Videre skal oppdragsgiver gi gratis, direkte og ubegrenset elektronisk tilgang til konkurransegrunnlaget, jfr. FOA § 14-3, som betyr at det ikke kan kreves betaling eller registrering for å få tilgang.

For at løsningen skal være i samsvar med gjeldende regelverk må oppdragsgivere stille krav til at løsningen blir oppdatert innen lovendringer trer i kraft, se krav 1.a.1 og  1.a.3. KGV-leverandørene må også holde seg orientert om relevante regelverksendringer og ha en strategi for å gjøre nødvendige oppdateringer, se krav 1.a.2.

I forslaget til kravspesifikasjon har vi vurdert at endringer i regelverket som må implementeres i løsningen for at anskaffelsen skal være lovmessig er skal-krav. Dette gjelder for eksempel funksjonalitet for ESPD,  se krav 2.b.5, 2.b.7 og 2.b.9. Det kan være en fordel å evaluere som et tildelingskriterium (bør-krav) hvordan, hvor intuitivt og brukervennlig leverandørene har løst dette i sitt system.

Krav som knytter seg til støtte for nye arbeidsflyter, for eksempel utvidelse av eBevis  eller implementering av kravbank (les om dette nedenfor) behøver ikke være absolutte og kan evalueres under tildelingskriteriet kvalitet, se for eksempel krav 10.2 eller gjennom et kontraktskrav om videreutvikling.

Forslaget til kravspesifikasjon inneholder begge typer krav nevnt ovenfor. Dere må gjennomgå disse nøye og selv vurdere om noen skal endres, fjernes eller gjøres om til et kontraktskrav.

Forskrift om universell utforming av ikt-løsninger (ikt-forskriften) stiller krav om universell utforming (uu) av IKT-løsninger som er tilgjengelige for allmenheten. KGV for oppdragsgivere er ikke i denne kategorien siden det kun skal brukes internt i virksomheten, men funksjonaliteten ut mot leverandørene vil være omfattet og definert som "allmenheten". De elementene i KGV som er tilgjengelig for tilbydere og andre eksterne, herunder også dokumenter, må dermed oppfylle kravene til uu.

Det er også en bevegelse mot at stadig flere typer løsninger får uu-krav, særlig nå når EUs webdirektiv (WAD) blir innført i Norge fra januar 2022. WAD vil ikke i denne omgang få konsekvenser for saksbehandlingsløsninger og fagsystemer. Det er likevel på det rene at FOA § 15-2 stiller opp en plikt til å «ta hensyn til universell utforming» i anskaffelser som skal brukes av personer, med mindre unntak er særlig begrunnet. Dette tilsier at det skal vurderes krav til uu også til de delene som kun er tilgjengelige for oppdragsgivers ansatte.

For å ikke bryte med ikt-forskriften, anbefales oppdragsgiver å stille som obligatorisk krav at de deler av løsningen som eksponeres mot allmenheten skal oppfylle gjeldende tekniske krav i ikt-forskriften. Det vil si 35 suksesskriterier på nivå A og AA i WCAG 2.0, og 49 suksesskriterier på nivå A og AA i WCAG 2.1 når WAD blir innført. Eksempler på slike nettsider er landingssiden som leverandør eller andre kommer til når de lenkes fra kunngjøringen på Doffin, siden for utfylling av ESPD og levering av tilbud. Se krav 1.b.6. Oppdragsgiver som lyser ut en anskaffelse før WAD trer i kraft bør vurdere å inkludere et krav i kontrakten som sikrer samsvar med kravene som kommer med WAD.

Informasjonssikkerhet og personvern

Under punktet om Risikovurdering for anskaffelse av skytjeneste er det anbefalt å gjennomføre en ROS-analyse spesifikk for deres virksomhet. Denne hjelper dere til å stille relevante krav til informasjonssikkerhet. Kravene som anbefales her i veilederen gjelder mer generelt ved kjøp av KGV, og er utarbeidet etter en generell ROS-analyse og bruk av risikobanken på DFØs markedsplass for skytjenester.

Nærings- og fiskeridepartementet har på sine sider om anskaffelsesregelverket under punkt 3.5 publisert Retningslinjer for sikkerhetstiltak ved elektronisk konkurransegjennomføring.  Sjekk også ut Datatilsynets sjekkliste for programvare, produkt, applikasjon, system, løsning eller tjeneste.

Sikkerhet under overføring av tilbud og forespørsler om deltakelse

Som oppdragsgiver må du ha en løsning som minimum:
• I tilstrekkelig grad bekrefter at leverandøren er hvem han sier han er
• Kan knytte leverandøren til det aktuelle tilbudet eller den aktuelle forespørselen om å delta i konkurransen i tilstrekkelig grad.
• Kan fastslå når tilbudet eller forespørselen om deltakelse er mottatt og åpnet med tilstrekkelig sikkerhet.
• Kan spore alle forsøk på overtredelse av sikkerhetsbestemmelser.

I forslaget til kravspesifikasjon finner du sikkerhetskrav som ivaretar disse punktene.

Sikkerhet under lagring av informasjon i KGV

Når KGV har mottatt dokumenter, for eksempel forespørsel om deltakelse i konkurransen, tilbud eller dokumentasjonsbevis må løsningen ha funksjonalitet som sikrer disse i henhold til gjeldene regelverk:

• Tilbudenes innhold skal holdes konfidensielt og beskyttes mot uautorisert innsyn under lagring
• Ingen skal ha tilgang til innholdet i dokumentene før fristen for mottak av tilbud eller forespørsler har løpt ut
• Bare autoriserte personer skal siden ha tilgang
• Dokumentenes integritet skal bevares
• Forsøk på overtredelse av reglene skal i tilstrekkelig grad kunne spores

Andre sikkerhetskrav

Dersom du som oppdragsgiver vil ha mulighet for å stille krav om at tilbud eller enkeltdokumenter skal krypteres/beskyttes særskilt, må du kreve en løsning som støtter dette.

I forslaget til kravspesifikasjon har vi lagt inn krav om avansert elektronisk signatur som et bør-krav. For de fleste anskaffelser vil ikke krav om avansert elektronisk signatur gi en økt sikkerhet som står i forhold til den økte kompleksiteten og kostnaden for oppdragsgiver og leverandør.

Særlig om personvern

I tillegg til å gjennomføre en ROS-analyse må dere også kartlegge og få oversikt over behandlingen av personopplysninger i løsningen. Et KGV vil behandle personopplysninger, for eksempel navnet til brukerne av systemet, eller personopplysninger knyttet til en leverandør som deltar i en konkurranse.

Oppdragsgiver er behandlingsansvarlig og må sørge for at behandlingen skjer i samsvar med personopplysningsloven og personvernforordningen (GDPR). KGV-leverandøren skal behandle personopplysninger på oppdragsgivers vegne og er databehandler. Oppdragsgiver må derfor inngå en databehandleravtale med leverandøren av KGV. Dere kan bruke DFØs mal for databehandleravtale. Forslaget til kravspesifikasjon inneholder krav om at leverandøren må si eksplisitt i fra dersom han har forbehold til databehandleravtalen, se krav 6.a.2.

Kravene i forslaget til kravspesifikasjon og databehandleravtalen bidrar til å ivareta personvern i KGV, men dere er selv ansvarlige for å gjøre vurdering av om vernet er tilstrekkelig. Du finner veiledning om hvordan dette skal gjøres i Datatilsynets sjekkliste for virksomhetens plikter og sjekkliste for kravsetting.

NB! Mal for databehandleravtale håndterer ikke overføringer av personopplysninger ut av EU/EØS, såkalte tredjeland.

Tilgangstyring

Denne delen tar for seg hvilke type brukere og roller det kan stilles krav om at KGV støtter og hvilke tilganger disse kan ha.

Brukere, roller og tilganger

Antall og type brukere er ett av priselementene i anskaffelsen. Oppdragsgiver må vurdere hvor mange og hva slags brukerbehov dere har og beskrive dette slik at leverandørene har et grunnlag for sitt pristilbud.

Typer lisenser kan være faste lisenser eller flytende lisenser.

Faste lisenser. Ofte har virksomheten en innkjøpsenhet med et antall medarbeiderne som bør være faste brukere. Disse kan ha ulike tilganger, eller alle kan ha tilgang til alt. Er arbeidsprosessen alltid slik at det kun er disse brukerne som jobber i KGV, kan fast lisens fungere for din virksomhet. Faste lisenser fungerer som oftest slik at det er et antall navngitte brukere som har en lisens hver.

Flytende lisenser. Det er vanlig at medarbeidere i virksomheten gjør eller deltar i anskaffelser enkelte ganger, kanskje det er behovshavere som også håndterer anskaffelsen i KGV. Da er det ikke ønskelig å betale en full lisens for alle disse som bruker KGV innimellom. Da kan det være mer hensiktsmessig at KGV har et gitt antall brukere som kan ha tilgang til KGV samtidig. Dette kalles ofte flytende lisenser. Denne måten å håndtere tilgang til KGV på vil likevel kreve at de som har tilgang logger seg på med navn og passord, men da kan flere brukere ha tilgang.

Enkelte systemer har også ulike typer brukere som gjør at det kan være en kombinasjon av faste brukere med full tilgang og et gitt antall brukere med begrenset tilgang. Det kan være hensiktsmessig i en anskaffelse av KGV å beskrive hvordan arbeidsprosessen i en anskaffelse foregår, slik at leverandør kan foreslå og beskrive hvordan brukertilgangene understøtter måten dere jobber på. Det blir også en vurdering om tilganger skal være et tildelingskriterium eller formuleres som noen absolutte minimumskrav.

Tilgangsstyring. Det er viktig at systemet er i stand til å sette rettigheter og tilganger i tråd med virksomhetens rutiner for hvem som har rettigheter og ansvar for hva i anskaffelsesarbeidet. Flere roller kan gjerne tildeles samme person, men vi anbefaler tydelige rutiner for fordeling av tilganger som gjør det mulig å publisere en anskaffelse, redigere anskaffelsesdokumenter og inngå kontrakt. Vi har vurdert det som lite hensiktsmessig å definere krav for hver enkelt rolle, slik at forslaget til kravspesifikasjon foreslår en generell formulering hvor oppdragsgiveren må beskrive sine behov.

Dette vil variere en del mellom virksomhetene, men eksempler på vanlige roller og tilganger er beskrevet nedenfor. Listen er ikke uttømmende.

• Administrator: Administrerer roller, gir tilganger og gjør systemendringer innen virksomheten
• Lesetilgang: Tilgang til å lese alle dokumenter, kopiere, men ikke redigere. Dette kan være en tilgang ledere eller representanter fra fagenheten som skal bruke det som anskaffes ønsker, og kan gjelde både dokumenter under arbeid, innkomne tilbud, evalueringer og forslag til tildeling av kontrakt.Tenk gjennom hvor mange lesetilganger dere trenger.
• Redigering: Denne tilgangen gir mulighet for å opprette konkurranse, utarbeide anskaffelsesdokumenter, besvare spørsmål fra leverandørene, kunngjøre konkurranse og foreta endringer i anskaffelsesdokumentene etter publisering etc.
• Evaluering av tilbud: Gir tilgang til å evaluere tilbud i løsningen ved å gi poeng/kommentere på tildelingskriteria.
  Denne tilgangen gis til den hos oppdragsgiver som er autorisert til å inngå kontrakt med valgte leverandør, for eksempel en avdelingsdirektør eller øverste leder.

Andre eksempler på roller og brukertilfeller. Revisjon, ekstern konsulent som skal bistå i anskaffelse, avtalebruker, eksterne brukere, adgang til å generere og ta ut standard- eller styringsrapporter.

Brukervennlighet

Vi anbefaler at dere stiller krav til løsningens brukervennlighet og vektlegger dette under tildelingskriteriet kvalitet, se krav 1.b.8.

Brukervennlighet som tildelingskriterium kan være vanskelig å evaluere, og det er nødvendig at leverandørene har tilstrekkelig informasjon til å forstå hva oppdragsgiver legger i kriteriet. Brukervennlighet handler i denne sammenhengen om intuitiv arbeidsflyt, antall klikk for å utføre noe, gode hjelpetekster og eventuelt funksjonalitet for single-sign-on. Responstid kan også inkluderes her.

En oversiktlig test av brukervennlighet er en kombinasjon av at:

• Det defineres et utvalg sentrale arbeidsflyter og disse testes av en gruppe erfarne innkjøpere som ikke kjenner systemet, om det lar seg gjøre. Gitt et begrenset marked for KGV, må innkjøperne være bevisst på det faktum at de kanskje kjenner den ene løsningen godt og den andre ikke i det hele tatt og forsøke å ikke la det prege evalueringen. Den enkelte tester gir en score, hvor både flyt, antall klikk og antall feilklikk inngår i vurderingen. Siden dette er en individuell kvalitativ vurdering, vil en slik test ikke gi et fullt ut objektivt resultat, men kunne indikere brukervennlighet.
• Sentrale arbeidsoperasjoner får en maksimal responstid, for eksempel hvor lang tid det tar å åpne tilbud, laste opp dokumenter, validere egenerklæringsskjema eller generere sentrale rapporter. Flest mulig kvantifiserbare elementer vil være en fordel, for eksempel antall sekunder, antall klikk osv.
• Testgruppen jobber seg gjennom løsningens brukerdokumentasjon ved å gjøre alle operasjoner beskrevet der, på den måten utførelsen er beskrevet. Mengden feilklikk, antall ganger testerne må gå tilbake og gjøre oppslag i dokumentasjonen, antall ganger testerne må gå tilbake og gjøre en oppgave på nytt etc. indikerer brukervennlighet.
  Denne siste testen også gjenbrukes i godkjenningsprøven. Godkjenningsprøven er beskrevet i standardavtalen SSA-L punkt 3.3 med eventuelle tillegg i bilag 3.

I tillegg til brukertesting har flere virksomheter som har anskaffet KGV god erfaring med å be om en demonstrasjon av løsningen hvor leverandøren viser frem hvordan et eller flere brukertilfeller håndteres. Demonstrasjonen kan være en del av dokumentasjonen av tildelingskriteriet brukervennlighet, se krav 1.b.8.. Brukertilfellene som utarbeides av virksomheten bør være typiske for virksomhetens anskaffelser. Skal evaluering av brukertilfellene inngå som dokumentasjon for et tildelingskriterium, må beskrivelsen av brukertilfellene vedlegges anskaffelsesdokumentene som vedlegg til SSA-L, bilag-1.

Statistikk og styringsdata

Statistikk og styringsdata kan enten hentes ut gjennom et sett med definerte rapporter, eller at KGV tilbyr en rapportgenerator som kan lage rapporter på en generisk valgt kombinasjon av ett eller flere felt i løsningen. De fleste KGVer har et sett med rapporter som inngår i standardløsningen. Det er også mulig å definere spesifikt rapporter deres virksomhet har behov for i tillegg til standardrapporter. Forslaget til kravspesifikasjonen legger til rette for at leverandøren beskriver sin funksjonalitet for rapporter, og at dette inngår i tildelingskriteriet kvalitet, se krav 7.4.

For å definere rapporter utover standardrapporter, må det lages ett eller flere krav for dette. Kravene må få status «skal» eller «bør», avhengig av hva dere ønsker. Siden dette vil variere fra virksomhet til virksomhet har ikke forslaget til kravspesifikasjon slike krav. Ha også et bevisst forhold til hvilke rapporter som er nødvendige og hvilke som er «kjekt å ha», for alle krav har en kostnad. Spend-analyser, rapportering på miljøkrav, lojalitet til rammeavtaler, innovative anskaffelser er eksempler på aktuelle rapporter.

Vi anbefaler å gå i tett dialog med ledelsen for å avdekke konkrete behov for innkjøpsdata. Se også oversikt over eksempler på styringsparametere for anskaffelser. I i tillegg må innkjøpsenheten vurdere hva de har behov for av data.

For enkelte oppdragsgivere kan også datafangst i råformat være aktuelt, dersom oppdragsgiver har eget dataanalyseverktøy og har kompetanse til denne type analyser. Det er laget et forslag til krav (7.2) for de som dette er relevant for.

Dokumentasjon, opplæring og brukerstøtte

Standard dokumentasjon når systemet leveres, dekkes av SSA-L-avtalens punkt 3.4. Dette vil typisk være standard produktbeskrivelse, brukerveiledning og annen dokumentasjon som eksempelvis dokumentasjon av ulike miljøer for opplæring og produksjon, se krav 5.7. DFØ har i forslaget til kravspesifikasjon foreslått et krav om oppdatert brukerveiledning (krav 5.5) som i tillegg sikrer at brukerveiledningen også oppdateres når systemet blir oppdatert. Forslaget til krav om brukerveiledning inkluderer også veiledning til tilbydere, krav 5.1.

Virksomhetens behov for opplæring i systemet bør vurderes på bakgrunn av aktuelle brukeres eksisterende kompetanse og kvaliteten på brukerdokumentasjonen som skal følge systemet. Et viktig moment ved vurderingen vil være om innkjøpsarbeidet har brukere som vil arbeide i systemet nesten daglig, eller om innkjøperne sjeldnere benytter systemet og derfor vil ha behov for mer omfattende veiledningsmateriell som alltid er tilgjengelig.

Behovet for brukerstøtte har nær sammenheng med virksomhetens organisering av innkjøpsarbeidet. Brukerstøtte for et stort antall brukere er erfaringsmessig en kostnadsdriver. Erfaring har også vist at brukerstøtter mottar mange anskaffelsesfaglige spørsmål som går langt utenfor bruk av selve systemet, og som leverandøren har begrenset kompetanse til å besvare. Siden offentlige virksomheter og hvordan disse er organisert er ulikt, er det viktig at virksomhetene selv vurderer om de ønsker å kjøpe brukerstøtte sammen med KGV eller ta brukerstøtte selv. Forslaget til kravspesifikasjon har ingen krav om brukerstøtte.

Innebygd arkivering

Det er Arkivlova som regulerer hvordan man skal dokumentere offentlig virksomhet og  skape arkiv. Arkivlova er under revisjon for å bli bedr tilpasset en digital hverdag, og Arkivverket har gitt signaler om at virksomhetene bør tenke nytt rundt hvordan arkiv blir skapt og vedlikeholdt. Dagens Noark-standard vil ikke bli videreutviklet. I fagsystemer som KGV overføres det i dag dokumentasjon til egne Noark sak/arkiv løsninger via integrasjoner, men utviklingen går mot at selve fagsystemet i blir et arkiv. Denne tankegangen er omtalt som innebygget arkiv, som består i at arkivering skjer løpende og automatisk i det systemet du vanligvis jobber i. Fokus er på at dokumentasjon er ekte, dekkende, pålitelig, i sammenheng og anvendbar.

Det er en utfordring av vi nå er i en mellomfase der vi venter på en klar tidslinje for når ny reglering er klar. Arkivloven er sendt på sin andre høringsrunde med frist for innspill den 14. januar 2022. Arkivverket har satt i gang arbeid med innebygd arkivering, og det er flere piloter som nå tester ut innebygd arkiv.

DFØs vurdering er at KGV allerede oppfyller mange av de kravene som stilles til et innebygget arkiv, slik som versjonshåndtering, låsing av dokumenter, håndtering av personvern og prosess-støtte. Men på nåværende tidspunkt vil det være vanskelig å stille konkrete krav til innebygd arkiv. DFØ har dialog med Arkivverket for å bistå i å realisere innebygd arkivering for fagsystemer på anskaffelsesområdet, og innebygd arkiv er et krav DFØ ønsker at oppdragsgivere på sikt skal stille ved anskaffelse av nytt KGV. Det er altså en gyllen anledning til å søke samarbeid med flere behovshavere og gjennomføre en anskaffelse der man utfordrer markedet som understøtter innebygget arkiv-tankegangen.  Oppdragsgivere som er interesserte i dette bes ta kontakt med DFØ og Arkivverket for mulig samarbeid på området.

Dersom dere må anskaffe KGV i dag, men ikke ønsker en innovativ anskaffelse, anbefaler DFØ å la være å investere i nye en-til-en sak-/arkivintegrasjoner og spesialtilpasninger, men heller basere integrasjoner på standardiserte integrasjoner som for eksempel Geointegrasjon eller SvarInn. Vi anbefaler at oppdragsgiver ber leverandøren beskrive sin standard integrasjon.  

Oppsett, drift, vedlikehold og utvikling

KGV som kjøpes som en skytjeneste (SaaS) installeres ikke i virksomhetens driftsmiljø, og virksomheten har verken ansvar for å følge opp driften av løsningen eller oppdateringer og feilrettinger. Det følger av SSA-L at KGV-leverandøren har ansvar for alt som har med drift og vedlikehold å gjøre. Den årlige lisenskostnaden skal dekke leverandørens løpende drift og vedlikehold.

Opplæring bør følge av bilag 1 eller 2 i SSA-L, og oppdragsgiver bør tenke gjennom hva som er tilstrekkelig. For enkelte større oppdragsgivere kan det være aktuelt å stille et krav om at leverandøren skal tilby flere kursmiljø for opplæringsformål. Merk at dette kravet kan være kostnadsdrivende dersom du skal ha kursmiljø eksklusivt for din virksomhet. Dette kravet bør i så tilfelle prises separat. Ofte kan det være godt nok å ha et kursmiljø som eventuelt deles med flere oppdragsgivere. Se krav 4.1 i kravtabellen.

Forholdet mellom oppdragsgiver og KGV-leverandøren reguleres ved at det etableres en tjenestenivåavtale eller SLA (Service Level Agreement) med krav til blant annet tilgjengelighet, responstid i løsningen, responstid på retting av avvik/feil, varsel ved feil/nedetid og andre målbare størrelser. Tjenestenivåavtalen skal også beskrive hvilke tiltak som skal iverksettes dersom tjenestenivået ikke samsvarer med det som er avtalt. Formålet med tjenestenivåavtalen er å konkretisere tjenestenivået slik at begge parter har en felles oppfatning av hva som skal leveres.

KGV-leverandøren vil ofte ha en standardisert SLA. Oppdragsgiver kan velge å legge denne til grunn og angi rammene for tjenestenivået. Da må rammene fylles ut i bilag 1 kravspesifikasjon, og leverandøren legge ved sin tjenestenivåavtale i bilag 4. Vi anbefaler ikke å stille krav til en garantert oppetid 24/7, fordi dette vil være svært kostnadsdrivende. Det er heller ikke sikkert leverandøren kan tilby sin standardløsning dersom dere stiller strengere krav til tjenestenivå enn det som er vanlig i bransjen. Det er lurt å sjekke med markedet hvilket tjenestenivå som er vanlig før rammene settes.

Her er noen punkter som bør dekkes av tjenestenivåavtalen og fylles ut av leverandør i SSA-L bilag 4:

• Krav til leverandørens behandlings- og responstid ved feil som meldes fra Kunden
• Krav til oppetid og tilgjengelighet av tjenesten, for eksempel alle hverdager mellom 8-16.
• Forventet responstid i løsningen, for eksempel hvor mange sekunder det tar å navigere fra en side til neste. Leverandøren kan beskrive hva som er forventet responstid på typiske aktiviteter i løsningen, for eksempel lagring av endringer.
• Beskrivelse av brukerstøtte, oppetid for brukerstøtte og forventet responstid
• Beskrivelse av rutiner for planlagt vedlikehold med informasjon om nedetid og varsling i forkant.
• Beskrivelse av rutiner for vedlikehold som ikke er planlagt med informasjon om varsling i forkant
• Kompensasjon og tiltak dersom avtalt tjenestenivå ikke overholdes.

Utvikling omfatter all funksjonalitet som din virksomhet bestiller utover det leverandøren ved kontraktstidspunktet kan tilby. For eksempel er dette funksjonalitet for kontraktsadministrasjon, integrasjon mot bestiller- eller økonomisystem, mot enhetsregisteret, eller funksjonalitet for innebygd arkivering. Noe slik utvikling vil også være av kommersiell interesse for leverandøren å utvikle, og dersom det er sentrale behov hos virksomheten kan dere for eksempel inngå et innovasjonspartnerskap for å få utviklet slike løsninger.

Det er hensiktsmessig å stille krav om at din virksomhet skal få tilgang til all ny funksjonalitet som blir utviklet som en del av standardløsningens vedlikehold. Dette er for eksempel særlig aktuelt for det europeiske egenerklæringsskjemaet (ESPD) som har vært implementert i KGV en stund, men hvor ny versjon skal implementeres. I forslaget til kravspesifikasjon krav nummer 10.1 og 10.2 har vi lagt til rette for dette. Hensikten med at leverandøren beskriver sitt veikart for løsningen er å fange opp endringer som kommer og klargjøre hva som vil inngå i standardløsningen og hva som er tillegg. Slik vet dere hva dere kan ta i bruk uten å betale ekstra vederlag og slippe overraskelser i kontraktsperioden.

Levering og godkjenning

Når løsningen er levert bør dere som kunde gjennomføre en godkjenningsprøve for å undersøke om leveransen er i samsvar med det som er avtalt. At dere vil gjennomføre en godkjenningsprøve fremgår av SSA-L punkt 3.3.

Art og omfang av godkjenningsprøven skal beskrives i SSA-L, Bilag 3.
Godkjenningsprøven bør omfatte både funksjonalitet i selve løsningen, responstid og brukervennlighet, dokumentasjonen som skal følge leveransen og eventuelle integrasjoner mot andre system som inngår i leveransen. En relativt ressurseffektiv godkjenningsprøve er å ta utgangspunkt i den leverte brukerdokumentasjonen, og i praksis utføre alle arbeidsoperasjoner som er beskrevet der. Skal teknisk personell hos dere ha en rolle i installasjon og/eller oppgraderinger og integrasjoner skal det leveres dokumentasjon også på dette, og også disse arbeidsoperasjonene bør testes i godkjenningsprøven.

Krav som sikrer effektiv konkurransegjennomføring

I Forslaget til kravspesifikasjon har vi lagt inn en rekke krav som sikrer at KGV støtter oppdragsgiver i gjennomføring av anskaffelsesprosessen.

Krav 2.c.10. er et generelt krav om at løsningen bør støtte oppdragsgiver i elektronisk konkurransegjennomføring, og her kan du gi leverandørene som f.eks. gir støtte for flere elektroniske prosesser enn Skal-kravene dekker uttelling.

Nedenfor har vi omtalt enkelte tema nærmere, og DFØ vil vurdere utvide denne delen til en senere versjon av veilederen.

Lage anskaffelsesprotokoll

Oppdragsgiver er pålagt å føre protokoll over de viktigste forholdene ved anskaffelsen, jfr. FOA §§ 10-5 og 25-5. Et KGV bør ha integrert funksjonalitet for elektronisk å kunne etablere, redigere og arbeide med protokollen. Protokollen bør ideelt sett etableres automatisk av KGV tidlig i konkurransen og oppdateres automatisk underveis i anskaffelsen. En del virksomheter ønsker å kunne utvide protokollen med informasjon utover det FOA krever, for eksempel om det er stilt eksplisitte miljøkrav.

Forslaget til kravspesifikasjon har et krav som dekker minimumsinnholdet i anskaffelsesprotokollen, men oppdragsgiver må selv eventuelt stille krav til funksjonalitet og felt utover lovens krav, se krav 2.c.1-2.c.3.

Lage anskaffelsesdokumenter

Følgende dokumenter er i FOA § 4-2 b) definert som en del av anskaffelsesdokumentene:

• Kunngjøringen
• Konkurransegrunnlaget
• Det europeiske egenerklæringsskjemaet (ESPD)

Vi understreker at «dokumenter» i denne sammenhengen ikke begrenser seg til papirbaserte dokumenter i Word eller lignende. Vi forstår dokument-begrepet vidt, i tråd med definisjonen i offentleglova § 4 (1), slik at KGV-leverandørene står friere til å tilby gode digitale løsninger på hvordan f.eks. kunngjøringen eller konkurransegrunnlagsmalen ser ut

I forslaget til kravspesifikasjon har vi laget et krav om at KGV bør ha funksjonalitet for utarbeidelse av anskaffelsesdokumentene, se krav 2.c.4. Kravet åpner for at oppdragsgiver kan kan premiere leverandører som løser dette  på en slik måte at mest mulig fylles ut automatisk, og at det som fylles ut kan gjenbrukes senere i konkurransen og evt. som basis/mal for andre konkurranser. Både kunngjøring, konkurransegrunnlag og ESPD er egnet for denne type gjenbruk av informasjon/data og bør kunne etableres uten å manuelt fylle ut alt på nytt hver gang. Mulighet for at flere kan arbeide samtidig på  dokumentene og god orden på  ulike versjonene er elementer som forenkler arbeidsflyten.

Spørsmål, svar og endringer

KGV bør ha funksjonalitet for at leverandørene kan legge inn sine spørsmål, uten at andre ser hvem som har stilt spørsmålet, og at spørsmålene kan besvares på en måte som er åpent tilgjengelig for alle tilbyderne i konkurransen. Det er lagt opp til at leverandørene kan besvare sin funksjonalitet for dette under 2.c.10.

Rettelser, suppleringer eller endringer i konkurransegrunnlaget skal umiddelbart sendes til leverandører som har meldt sin interesse, og løsningen bør ha funksjonalitet for dette. Sporing og versjonskontroll av kunngjorte endringer er en forutsetning, se krav 2.c.21.

Innlevering av tilbud og forespørsel om deltakelse i konkurransen

Mottak av tilbud og forespørsler om å delta i konkurransen er omfattet av plikten til bruk av elektronisk kommunikasjon i FOA kapittel 22 og er ivaretatt gjennom krav 2.c.9.

Det er få leverandører som har et eget system for å levere et elektronisk tilbud, og derfor er leverandør avhengig av å kunne få levere tilbud og fylle ut en ESPD via oppdragsgivers KGV. For oppdragsgiver er det en fordel dersom leverandører oppfatter funksjonaliteten som enkel, rask og selvforklarende, slik at leverandøren ikke vegrer seg for å levere tilbud. KGV som har god funksjonalitet med hjelpetekster og mulighet for support bør få uttelling for dette, se krav 2.b.9 og 2.c.9.

Velge tilbud og inngå avtale

Løsningen må ha funksjonalitet som hjelper oppdragsgiver gjennom anskaffelsesflyten og varsler når dokumenter og/eller aktiviteter er utestående. Kritiske aktiviteter, som for eksempel utløp av vedståelsesfrist må varsles i god tid før de utløper, eventuelt også med påminnelser dersom de fortsatt står som utestående.

Oppdragsgivere kan vurdere om dere også skal stille krav om funksjonalitet knyttet til forhandlinger. Det kan være aktuelle maler, logging av alle aktiviteter i forhandlingsfasen og funksjonalitet for god logistikk på oppdaterte versjoner frem til endelig tilbud. Forslaget til kravspesifikasjon inneholder et slikt krav i krav nummer 2.c.15.

Elektronisk konkurransegjennomføring

Dynamiske innkjøpsordninger

De fleste KGV støtter DPS, men har ulik grad av digital støtte for prosess-stegene. DPS stiller krav om en fullt ut elektronisk prosess, og all kommunikasjon skal foregå elektronisk, jfr. FOA kapittel 26.

DFØ anbefaler at oppdragsgiver vurderer å be om funksjonalitet for å kategorisere ut fra type kjøp, geografi, verdi og/eller andre kategorier. Da kan en leverandør kvalifisere seg for en eller flere kategorier, for eksempel type håndtverkstjenester i et geografisk område. Dersom DPSen ikke er kategorisert, vil alle leverandører få tilsendt alle invitasjoner til å gi tilbud.

Oppretter flere oppdragsgivere DPS i fellesskap, for eksempel ved innkjøpssamarbeid, bør oversikten over kvalifiserte leverandører kunne distribueres til alle oppdragsgivere, uansett hvilket KGV de har. Denne listen blir også kalt leverandørliste. Det vil gjøre det mulig for den enkelte oppdragsgiver å sende tilbudsinvitasjon til leverandører for aktuell kategori (for eksempel geografisk), selv om de har et annet KGV enn oppdragsgiver som kunngjorde og etablerte DPS. Se nærmere beskrivelse av prosessen for DPS.

Et nytt element i DPS er etablering av Kravbank. Kravbank er et verktøy som DFØ har utviklet for å gjøre oppdragsgiver i stand til å generere en heldigital kravspesifikasjon, og mal for tilbudsinnlevering basert på standardiserte krav og forhåndsdefinerte svaralternativer. På denne måten legges det til rette for automatisert evaluering. Se mer om Kravbank i eget kapittel.

Oppdragsgivere bør stille krav til at KGV-løsningen som et minimum skal kunne brukes til å håndtere Kravbank-filer som del av konkurransedokumentene, og som del av tilbud som leveres inn. Kravbank-filer er PDF-filer med et strukturert og maskinlesbart tillegg, og filformatet bør ikke være noe problem for KGV-løsningene å håndtere. På sikt bør oppdragsgiver vurdere krav om integrasjon av Kravbank-løsningen inn i KGV, enten som kontraktskrav eller som tildelingskriterium.

Oppdragsgivere som planlegger å bruke DPS som teknikk, bør ha et absolutt krav om at DPS kan gjennomføres digitalt, at det skal være mulig å håndtere Kravbank-filer som vedlegg både til oppdragsgivers konkurransegrunnlag og til tlibyders tilbud, samt at eBevis brukes i prosessen (krav 2.c.7). Størst mulig grad av digitalisering og effektiv og intuitiv gjennomføring av DPS kan settes som et tildelingskriterium.

Obligatoriske og anbefalte standarder i anskaffelsesprosessen

Gjennom Referansekatalogen for IT-standardar gis det informasjon om standarder som er pålagt eller anbefalt brukt innenfor de ulike fasene i anskaffelsesprosessen. Standardene utgjør strukturert, standardisert meldingsinnhold og er representert gjennom Elektronisk handelsformat (EHF). I konkurransegjennomføringsfasen er det obligatorisk å benytte EHF Egenerklæringsskjema (ESPD). jf. FOA §17-1. Oppdragsgivere må sette opp EHF ESPD som et skal-krav, se krav 2.b.7 og 2.b.8 i kravspesifikasjonen. Ny versjon av ESPD kommer i løpet av 2023, se i kapittelet om nytt europeisk egenerklæringsskjema.

I tillegg anbefales det i Referansektalogen for IT-standardar å benytte alle EHF-dokumenter som tilhører anskaffelsesdokumentene. Her skjer det en kontinuerlig utvikling i regi av Publication Office og OpenPeppol, og det anbefales at oppdragsgiverne setter opp støtte for anbefalte EHF-dokumenttyper som et bør-krav, se krav 2.b.10.  i forslaget til kravspesifikasjon.

Ny Doffin

DFØ utvikler en ny Doffin-løsning der det ikke lenger legges opp til funksjonalitet for å fylle ut kunngjøringsskjemaer direkte på Doffin. Det forutsetter at alle KGV eller andre markedsbaserte systemløsninger har denne funksjonaliteten, og at disse løsningene er allment utbredt blant oppdragsgiverne.

I dag har tilnærmet alle KGV funksjonalitet for å lage kunngjøringer og cirka 95% av alle kunngjøringer på Doffin kommer fra KGV, så det er svært få som bruker Doffin-funksjonaliteten for å fylle ut og publisere kunngjøringsskjema. Ny Doffin-løsning vil komme i produksjon våren 2023, og oppdragsgivere må sikre seg at alle typer kunngjøringer som de trenger vil kunne fylles ut via KGV.

Nye kunngjøringsskjemaer

EU-kommisjonen (forordning (EU) 2019/1780) har vedtatt nye kunngjøringsskjemaer (eForms) for offentlige anskaffelser. Måldato for obligatorisk bruk av disse i Norge er april 2023. Nye kunngjøringsskjemaer har en helt ny teknisk oppbygging, noe som vil medføre en større innføringsjobb for KGV-aktørene. I tillegg er det lagt opp til noe nasjonal tilpasning, men det vil i hovedsak være små tilpasninger.

DFØ er ansvarlig for å informere KGV-aktørene om de nasjonale tilpasningene. Fra sluttbrukers perspektiv vil selve spørsmålene i kunngjøringene fremstå som tilsvarende dagens kunngjøringsskjema, men rekkefølgen for utfylling og antall felter som kan fylles ut automatisk vil kunne variere mellom systemløsningene. Det bør derfor være viktig for oppdragsgivere at utfylling av kunngjøringene er mest mulig brukervennlig.

Frem til nye kunngjøringsskjemaer trer i kraft i Norge skal dagens skjemaer benyttes.

Nytt europeisk egenerklæringsskjema (ESPD)

Samtidig med nye kunngjøringsskjemaer vil ny versjon av ESPD lanseres. Tilsvarende som for nye kunngjøringsskjemaer, vil spørsmålene være relativt like som i dag. Dagens ESPD har flere overlappende felter med kunngjøringsskjemaene, og det er ønskelig å tilrettelegge for å unngå at sluttbrukere må svare på samme spørsmål flere ganger.

Endringene i ESPD vil være større for systemleverandørene enn for sluttbrukerne, siden systemleverandør vil være ansvarlig for å sørge for brukervennlighet og størst mulig grad av automatisk utfylling av felter og gjenbruk av informasjon.

DFØ er ansvarlig for å informere KGV-aktørene om ESPD-formatet og vil også oppdatere veiledning til sluttbrukere om utfylling. Oppdragsgivere bør stille krav om at ESPD er av gjeldende format og at denne er mest mulig brukervennlig for både oppdragsgiver og leverandør. Det anbefales også bruk av eBevis for innhenting av dokumentasjonsbevis.

Kravbank

Kravbank er et nytt verktøy som DFØ har utviklet for å gjøre oppdragsgiver i stand til å generere en heldigital kravspesifikasjon. Kravbank inneholder en mal for tilbudsinnlevering basert på standardiserte krav og forhåndsdefinerte svaralternativer. På denne måten legges det til rette for automatisert evaluering. Gjennom Kravbank generer oppdragsgiver en fil med sin kravspesifikasjon som gjøres tilgjengelig for leverandørene som en del av konkurransegrunnlaget. Leverandøren bruker igjen denne filen som utgangspunkt for sin besvarelse i Kravbank-løsningen, og leverer den som del av sitt tilbud gjennom KGV.

Kravbank kan benyttes helt frittstående eller kan integreres i en KGV. Kravbanker kan lages som maler og deles mellom oppdragsgivere. Kravbank eies og forvaltes av DFØ, og modulen og kildekoden til denne er åpen slik at KGV-leverandører og eventuelt andre aktører kan implementere den i sine løsninger.

Forslag til kravspesifikasjon

Nedenfor ligger DFØs forslag til kravspesifikasjon for anskaffelse av KGV. Den inneholder både skal-krav og bør-krav. Enkelte av kravene har informasjonstekst i klammer [..]. Klammene er ikke en del av kravet.

S= Skal-krav B= Bør-krav.

1. Generelle krav

1.a. Samsvar med regelverk
1.a.1.	Løsningen skal være tilpasset kravene i Lov og Forskrift om offentlige anskaffelser (LOA/FOA) til enhver tid.	S
1.a.2.	Leverandøren skal holde seg orientert om regelverksendringer og ha en strategi for å holde løsningen oppdatert til enhver tid.	S
1.a.3.	Ved lov- og/eller forskriftsendring skal løsningen tilpasses endringen fra dato endringen gjelder for. Kunden skal gis tilgang til oppdatert versjoner fra dato endringen trer i kraft.	S
1.a.4.	Løsningen bør ha støtte for å håndtere innsynskrav etter offentleglova.	B
1.b. Brukervennlighet
1.b.1.	Løsningen bør ha god funksjonalitet for å varsle brukeren om viktige frister.	B
1b.2.	Løsningen skal ha god responstid på alle vanlige transaksjoner og handlinger.	S
1.b.3.	Løsningen skal ha funksjonalitet for umiddelbar varsling dersom kunngjøringen feiler.	S
1.b.4.	Begrepsbruken skal være konsekvent i hele løsningen og i samsvar med begreper brukt i anskaffelsesregelverket.	S
1.b.5.	Løsningen bør legge til rette for at fremmedspråklige kan delta i anskaffelser.	B
1.b.6.	Alle deler av løsningen som er nettsider, som representerer oppdragsgiver og som eksponeres ut mot allmennheten skal oppfylle WCAG 2.0. Eksempelvis informasjon om konkurransen som lenkes fra Doffin, utfylling av ESPD.	S
1.b.7.	Løsningen bør være brukervennlig. [Oppdragsgiver må spesifisere hva det evalueres på her, for eksempel brukertesting og demo, se veileder for mer informasjon.]	B

2. Funksjonelle krav

2.a. Overordnet
2.a.1.	Løsningen skal synliggjøre hva som er obligatoriske felter, og må ha varslingsfunksjon for å gjøre bruker oppmerksom på mangler ved utfyllelse, for eksempel i ESPD.	S
2.a.2.	Løsningen skal ha støtte for elektronisk signering av dokumenter.	S
2.b. Planlegging og kunngjøring
2.b.1.	Løsningen bør ha funksjonalitet for gjennomføring av ulike former for dialog med markedet.	B
2.b.2.	Løsningen skal ha funksjonalitet for overføring av kunngjøringer til Doffin. Beskriv funksjonalitet for valg, utfylling og overføring av kunngjøringer.	S
2.b.3.	Løsningen skal til enhver tid støtte alle de gjeldende relevante kunngjøringsskjemaene. [Støtte innebærer mulighet for utfylling av skjemaene i løsningen]	S
2.b.4.	Løsningen bør støtte utarbeidelse av anskaffelsesstrategi.	B
2.b.5.	Løsningen bør kunne håndtere flere ESPD-skjema knyttet til samme tilbud eller forespørsel om deltakelse. [Oppdragsgiver må forklare hva som menes med "håndtere"]	B
2.b.6.	Løsningen skal gi god oversikt over alle kunngjorte anskaffelsesdokumenter.	S
2.b.7	Løsningen skal til enhver tid støtte gjeldende EHF-format for det europeiske egenerklæringsskjemaet (ESPD), jfr. FOA § 17-1.	S
2.b.8.	Løsningen skal  følge forvaltningsregimet satt av DFØ for EHF-format.	S
2.b.9.	Løsningen skal ha skal funksjonalitet for at oppdragsgiver kan fylle ut og publisere ESPD- forespørsel, og for at tilbyder kan fylle ut en ESPD-bekreftelse.	S
2.b.10.	Løsningen bør tilrettelegge for en effektiv arbeidsflyt ved utarbeidelse av anskaffelsesdokumentene.	B
2.c. Gjennomføring av konkurransen
2.c.1.	Løsningen skal ha funksjonalitet for fortløpende utfylling av anskaffelsesprotokollen.	S
2.c.2.	Løsningen bør ha funksjonalitet for tillegg av virksomhetsspesifikke felter i anskaffelsesprotokollen. Feltene skal kunne inneholde strukturerte data.	B
2.c.3.	Løsningen skal ha en oppdatert visning av anskaffelsesprotokollen som dekker gjeldende krav i anskaffelsesregelverket til enhver tid. (Endringer i protokollkravene skal være tilgjengelig fra samme tidspunkt som endringen i regelverket trer i kraft.)	S
2.c.4.	Løsningen skal ha funksjonalitet for utarbeidelse av konkurransegrunnlag i samsvar med bestemmelser i FOA, og legge til rette for gjenbruk av informasjon både innenfor en pågående anskaffelse og fra tidligere anskaffelser.	S
2.c.5.	Løsningen skal kunne vise Kundens logo og kjennetegn i dokumenter knyttet til anskaffelsen, for eksempel konkurransegrunnlag, kravspesifikasjon, invitasjoner, meddelelses- og tildelingsbrev.	S
2.c.6.	Løsningen skal skal støtte alle typer konkurranseprosedyrer som til enhver tid er tillatt i FOA.	S
2.c.7.	Løsningen skal støtte etablering og gjennomføring av konkurranser under dynamiske innkjøpsordninger (DPS). DPS skal gjennomføres digitalt og eBevis skal benyttes. Det skal være mulig å håndtere PDF-filer med strukturert innhold fra Kravbank som vedlegg til oppdragsgivers konkurransegrunnlag, og som vedlegg til tilbyders tilbud.	S
2.c.8.	Det skal være mulig å gjennomføre konkurranser om store parallelle rammeavtaler etter FOA del III, etter valgte prosedyre, herav bla. forhandlet prosedyre.	S
2.c.9.	Løsningen skal støtte elektronisk kommunikasjon i henhold til FOA kapittel 22, inkludert elektronisk tilbudsinnlevering. [Leverandøren må beskrive hvordan løsningen oppfyller dette kravet og hvilken funksjonalitet det gir de som deltar (tilbyderne) i oppdragsgiver anskaffelser.]	S
2.c.10.	Løsningen bør støtte oppdragsgiver i elektronisk konkurransegjennomføring. [Dette kravet er formulert åpent, slik at oppdragsgiver kan evaluere leverandørenes løsninger. Det gis uttelling der løsningen støtter flere elektroniske prosesser enn de absolutte kravene. Leverandøren skal beskrive hvordan løsningen støtter oppdragsgiver i elektronisk konkurransegjennomføring. ]	B
2.c.11.	Løsningen skal sikre at tilbud med tilhørende dokumenter sendes på en slik måte at uvedkommende ikke har tilgang, jfr. FOA § 22-3.	S
2.c.12.	Det skal gå an å fastslå tidspunkt for mottak og åpning av forespørsler om å delta i konkurranser nøyaktig.	S
2.c.13.	Løsningen skal ha funksjonalitet som hindrer leverandøren i å levere tilbud eller endre tilbud etter at tilbudsfristen er gått ut.	S
2.c.14.	Løsningen skal gi kvittering til leverandør for innlevert tilbud, og mulighet for at leverandøren kan endre innlevert tilbud frem til tilbudsfristen.	S
2.c.15.	Løsningen skal legge til rette for forhandlinger. Leverandør skal i tilbudet dokumentere at  løsningen håndterer forhandlinger av bla. parallelle rammeavtaler etter del I og del III av FOA.	S
2.c.16.	Løsningen skal ha funksjonalitet som tillater og loggfører ettersending av dokumentasjon etter utgått tilbudsfrist, i tilfeller hvor oppdragsgiver etterspør dette.	S
2.c.17.	Løsningen skal legge til rette for bruk av eBevis.	S
2.c.18.	Løsningen skal ha funksjonalitet for søk, lagring/oppbevaring og gjenbruk av tidligere innleverte dokumentasjonsbevis.	S
2.c.19.	Det skal være mulig å importere/definere egne evalueringsmodeller i tillegg til de som allerede ligger i løsningen.	S
2.c.20.	Løsningen skal være i samsvar med Retningslinjer for sikkerhetstiltak ved elektronisk konkurransegjennomføring.	S
2.c.21.	Løsningen skal ha sporing og versjonskontroll av kunngjorte endringer.	S
2.c.22.	Løsningen bør ha funksjonalitet for automatisk generering og utsendelse av meddelelse om valg av leverandør. Meddelelsen sendes alle berørte leverandører. Meddelelsen skal ha det innhold som er beskrevet i regelverket.	B

3. Brukere, roller og tilganger

3.1	Leverandøren skal levere et utkast til plan for etableringsfasen. Planen skal inneholde alle aktiviteter i forbindelse med implementering og estimert tidsbruk per aktivitet. Import av avtaler, metadata og andre dokumenter og informasjon skal være aktiviteter i implementeringsplanen.
3.2.	Løsningen bør ha tilgangstyring tilpasset oppdragsgivers arbeidsprosesser. [Oppdragsgiver må beskrive sine prosesser]
3.3.	Oppdragsgiver  skal selv kunne administrere roller og tilganger til løsningen for sine brukere innen rammen av avtalte antall lisenser.
3.4.	Leverandøren bør tilby flytende lisenser.
3.5.	Løsningen skal ha funksjonalitet for at eksterne både utenfor anskaffelsesteamet og eksterne utenfor virksomheten  kan arbeide med anskaffelsen.

4. Prosjektgjennomføring

4.1.	Leverandøren bør tilby et produksjonsmiljø, et kursmiljø og et testmiljø. Miljøene bør ha samme funksjonalitet og oppsett.
4.2.	Ved kontraktens avslutning skal det være mulig å eksportere all relevant data, herunder kontrakter og andre dokumenter, metadata etc. til et annet system. [Oppdragsgiver må spesifisere data som er relevant å overføre.]

5. Dokumentasjon, brukerveiledning og opplæring

5.1.	Leverandøren skal ha brukerveiledninger som er tilgjengelig for alle brukere i løsningen, både oppdragsgiver og tilbyder.	S
5.2.	Leverandøren skal tilby opplæring, og legge frem en plan for dette som en del av plan for etableringsfasen, jf. bilag 3.	S
5.3.	Leverandøren skal tilby opplæring på ny funksjonalitet/nye moduler ved endringer/oppdatering i løsningen.	S
5.4.	All brukerveiledning skal være på norsk og vedlegges som en del av tilbudet.	S
5.5.	Brukerveiledning skal være oppdatert til enhver tid.	S
5.6.	Leverandøren skal å stille en test/demoversjon av løsningen med brukerveiledning til disposisjon for Kunden i perioden mellom passert tilbudsfrist og tildelt kontrakt. Det bør være mulig med flere samtidige brukere. [oppdragsgiver må spesifisere fristen.]	S
5.7.	Leverandøren skal levere teknisk dokumentasjon av løsningen, inkludert informasjon om tjeneste-, data- og integrasjonsmodell. [oppdragsgiver kan beskrive nærmere hvilken dokumentasjon som skal gis.]	S

6. Personvern og krav til informasjonssikkerhet

6.a. Personvern
6.a.1.	Leverandøren skal følge de til enhver tid gjeldende regler for personvern.	S
6.a.2.	Vedlagt ligger databehandleravtalen som skal inngås. Leverandør må oppgi dersom det er reservasjoner til avtalen.	S
6.a.3.	Leverandøren skal beskrive hvilke personopplysninger som behandles i systemet og formålet med behandlingen.	S
6.a.4.	Beskriv hvordan Leverandøren jobber for å begrense behandlingen av personopplysninger til kun det som er nødvendig (dataminimering).	S
6.a.5.	I tråd med kravet om innebygd personvern skal alle innstillinger settes til det mest personvernvennlige som utgangspunkt.	S
6.a.6.	Leverandøren skal beskrive hvordan arbeid med personvern er organisert i virksomheten, med betydning for ivaretakelse av personvern i gjennomføringen av kontrakten, herunder om det er tydelige definerte roller og ansvar som er godt implementert i virksomheten.	S
6.a.7.	Leverandøren skal beskrive hvordan krav til innebygd personvern (personvernforordningen (GDPR) artikkel 25) blir ivaretatt i tjenesten som er tilbudt.	S
6.a.8.	Leverandøren skal beskrive hvordan bistand til Kunden for å ivareta den registrertes rettigheter, særlig retting, sletting og rett til innsyn gis.	S
6.a.9.	Alle personopplysninger skal behandles innenfor EU/EØS eller i land som er forhåndsgodkjent av Europakommisjonen. Dersom personopplysninger skal overføres (gjelder også fjernaksess) til tredjeland bes Leverandøren om å redegjøre for overføringsgrunnlag og tiltak som er iverksatt for å sikre tilsvarende beskyttelsesnivå som innenfor EU/EØS.	S
6.a.10.	Leverandøren skal gi oppdragsgiver tilgang til relevante deler av protokoll som føres etter personvernforordningen (GDPR) artikkel 30 nr. 2, på forespørsel. Leverandøren skal beskrive hvordan tilgangen gis.	S
6.b. Informasjonssikkerhet
6.b.1.	Leverandøren skal gi Kunden informasjon om hvor data lagres til enhver tid, både primærlokasjon og hva som er gjeldende reservelokasjon.	S
6.b.2.	Løsningen skal ivareta kravene til integritet og fortrolighet i henhold til FOA § 22-3 (1) til (3).	S
6.b.3.	All lagring og behandling av data i leverandørens systemer, skal skje i/fra EU/EØS eller i Europakommisjonens forhåndsgodkjente tredjeland. Leverandøren bes beskrive hvordan dette er ivaretatt.	S
6.b.4.	Alle handlinger som utføres av leverandøren skal logges. Loggen skal ikke kunne manipuleres. Kunden skal ha tilgang til loggene etter behov. Kunden har rett til å revidere leverandørens virksomhet knyttet til behandling av kundens data, eller å få innsyn i revisjonsrapporter fra en uavhengig tredjepart med revisjonsrett.	S
6.b.5.	Løsningen skal ha tilgangskontroll.	S
6.b.6.	Løsningen skal ha tilstrekkelig isolasjonsstyrke og robusthet i tilgangskontroll. Leverandør må tilby verktøy for administrasjon av kundens brukere og deres tilganger og ha tilstrekkelig støtte for bruk av eksterne identitetstilbydere.	S
6.b.7.	Leverandør skal forhindre uautorisert tilgang til sine datasenter samt beskytte mot tyveri, skade, tap og at utstyr svikter for å sikre kontinuerlig drift.	S
6.b.8.	Leverandøren skal ha prosess for å håndtere endringer for å sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages.	S
6.b.9.	Leverandøren bør ha en løpende prosess for å identifisere, vurdere og prioritere trusselbildet. Det bør også arbeides aktivt for å begrense sårbarheter.	B
6.b.10.	Leverandøren skal skille kundens tjenester og data fra andre kunder.	S
6.b.11.	Leverandøren skal dokumentere hvordan og når data slettes, samt hvordan han sikrer at slettede data ikke kommer på avveie eller kan gjenskapes.	S
6.b.12.	Det skal ikke være mulig å endre eller slette arkivverdig materiale før Kunden bekrefter at dette er overført til arkiv.	S
6.b.13.	Leverandøren skal definere, velge, dimensjonere og implementere passende kryptografiske mekanismer støttet av en tilstrekkelig nøkkeladministrasjonsinfrastruktur for å sikre sikker drift av tjenesten. Det gjelder både data i ro og datastrømmer.	S
6.b.14.	Data som overføres via nettverk skal sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester.	S
6.b.15.	Leverandøren skal ha tilstrekkelig sikkerhetsovervåkning av tjenesten og rutiner for varsling ved hendelser. Leverandør skal på forespørsel gi kunden tilgang til revisjonsrapporter for vurdering av sikkerhetsovervåkningen, vurdering av tilgangsstyringen til systemer og komponenter for leverandørens egne administratorer og hvilke prosedyrer og rutiner de har for varsling. Sikkerhetslogger skal overføres til kunden dersom kunden ber om det.	S
6.b.16.	Løsningen bør legge til rette for å sikre at passord ikke kommer på avveie.	S
6.b.17.	Løsningen bør kunne behandle avanserte, elektroniske signaturer i tråd med FOA §22-5 (5).	B
6.b.18.	Leverandøren skal yte bistand til Kunden dersom Kunden ønsker å avslutte avtalen. Leverandøren skal legge til rette for at Kundens data blir overført til Kunden eller til tredjepart utpekt av Kunden.	S

7. Rapporter, statistikk og styringsdata

7.1.	Kunden skal ha mulighet til å ta ut rapporter for å kontrollere fakturagrunnlag.	S
7.2.	Kunden bør ha mulighet til å trekke ut data for å foreta analyser. Eksempelvis database lesetilganger, datadumper eller annen rådata.	B
7.3.	Løsningen bør ha funksjonalitet for å la kunden definere egne rapporter på hvert enkelt felt, eller en kombinasjon av feltene i anskaffelsesprotokollen. [leverandøren bes beskrive hvordan de oppfyller dette kravet og hvilken funksjonalitet de har.]	B
7.4.	Løsningen bør kunne genere rapporter med sentrale data om kundens innkjøp, for eksempel: - Hvor mange kontrakter er inngått etter egendefinert tidsparameter -Hvor mange kontrakter er inngått i henhold til forskriftens Del I, Del II eller Del III - Antall kontrakter pr. leverandør - Antall kontrakter pr. saksbehandler - Antall kontrakter pr. enhet . [leverandøren bes beskrive hvordan de oppfyller dette kravet og hvilken funksjonalitet de har. ]	B

8. Ytelse, skalerbarhet og tjenestenivå

8.1.	Vedlagt ligger Kundens rammer for SLA. Leverandøren skal oppgi dersom det er reservasjoner til denne.	S
8.2.	Tjenesten skal være tilgjengelig for kunden når kunden har behov for tjenesten. Leverandøren skal kunne garantere oppetid og dokumentere historisk oppetid/tilgjengelighet.	S
8.3.	Nettsider/løsningen skal tilpasse seg brukerens skjermstørrelse.	S

9. Tekniske krav

9.1.	Løsningen skal tilbys som en tjeneste Kunden kan nå via nettleser (SaaS).
9.2.	Leverandøren og løsningen skal oppfylle de til enhver tid gjeldende obligatoriske krav i "Referansekatalog for IT-standarder i offentlig sektor".

10. Videreutvikling

10.1.	Kunden skal få tilgang til alle oppgraderinger leverandøren gjør av sin standardløsning. Oppgraderingene er inkludert i det løpende vederlaget.
10.2.	Leverandøren bør beskrive sitt veikart for ny teknologi, funksjonalitet og  implementering av lovpålagte endringer i   systemløsningen, og hvordan dette kan tas i bruk av oppdragsgiver. Beskrivelsen bør skille klart mellom utvikling inkludert i  standardløsning og utvikling som krever ekstra vederlag. Oppdragsgiver vil legge vekt på at veikartet er tydelig og forpliktende i 2-3 år fremover.