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 leverandører, 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 håndtere 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 bedre 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. Forslag til ny arkivlov hadde 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 arkiv 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 god anledning til å søke samarbeid med flere behovshavere og gjennomføre en anskaffelse der man utfordrer markedet på å understøtte innebygget arkiv.  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-/arkiv-integrasjoner 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 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 sin virksomhet. 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 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ører har ofte en standardisert SLA, så oppdragsgiver kan velge å sette noen ytre rammer/krav som utgangspunkt og be leverandør om å levere sin standard SLA innenfor disse rammene. 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. Sjekk med markedet hvilket tjenestenivå som er vanlig før du definerer rammene. 

Det er vanlig at KGV-leverandør setter opp jevnlig måling av responstid og oppetid. Be leverandør om å beskrive hvordan disse målingene og rapportering skal gjennomføres.

Her er noen punkter som bør dekkes av SLA:

• 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. Eksempler kan være funksjonalitet for kontraktsadministrasjon, integrasjon mot bestiller- eller økonomisystem, mot enhetsregisteret, eller funksjonalitet for innebygd arkivering. Noe utvikling vil være av kommersiell interesse for leverandøren å utvikle, så det kan være mulig å utforske muligheten for å inngå et innovasjonspartnerskap med leverandøren 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 er implementert i KGV, 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.