Avtalens punkt 1.1 Avtalens omfang

Bilag 1: Kundens kravspesifikasjon

Avtalens punkt 1.1 Avtalens omfang

UDI har behov for å anskaffe et fleksibelt, intuitivt og tilpasningsdyktig verktøy som støtter både dagens og fremtidens behov og som også kan tas i bruk utenfor IT- området. Se Konkurransegrunnlaget punkt 1.2 for en overordnet beskrivelse av behovet.

[Kravene besvares av leverandøren i Bilag 2]

Kapittel A: Brukervennlighet (brukeropplevelse)

- Tilbudt løsning bør være brukervennlig, enkel og intuitiv med oversiktlig oppbygging og ha et ryddig design tilpasset til den enkelte brukerrolle.

- Tilbudt løsning bør inneholde god funksjonalitet for online-hjelp og e-læring.

- Løsningen bør tilby dialogbokser, hjelpetekster, knapper og nedtrekksmenyer som kan hjelpe brukere å navigere i systemet med få tasteklikk, på en enkel og effektiv måte.

Kapittel B: Kravtabell

Forklaring til utfylling av kravtabell

Kravene i kravtabellen fordeles inn i følgende kategorier:

O = Obligatorisk krav. Dette er absolutte krav som må være oppfylt for tilbudet. Manglende oppfyllelse vil kunne medføre avvisning. Besvares med JA/NEI i kommentarfeltet.

Leverandøren kan i tillegg gi en nærmere forklaring i det tilhørende kommentarfeltet.

B = Bør-krav. Dette er ønsker som Kunden har til leverandørens tjenester og som det vil evalueres på i tildelingen. Krav besvares med JA/NEI, samt en nærmere forklaring i kommentarfeltet hvis det er angitt en «R» i kolonne “Kategori”.

Forklaring til kolonnen «Vekt»: Vekt 1-5 angir hvor viktig det enkelte kravet er for Kunden og hvor tungt kravet vektes i totalevalueringen av kravtabellen. Krav med vekt 5 veies tyngst.

R = Redegjør. Kolonnen «Kommentar/Redegjørelse» skal fylles ut med leverandørens beskrivelse av hvordan kravet oppfylles. Leverandør bes forklare nærmere i kommentarfeltet, eller henvise til informasjon i vedlegg. Nøyaktig referanse må oppgis.

Det kan benyttes vedlegg for besvarelsen, så fremt nøyaktig henvisning til aktuelt vedlegg og ev. punkt/avsnitt angis i kommentarfeltet.

Definisjoner:

«Bruker»: Fellesbetegnelse for alle brukere av systemet.

«Sluttbruker»: En person som kan melde inn henvendelser til servicedesk-portalen via godkjente kanaler. Sluttbrukere deles i to hovedkategorier:

- Interne sluttbrukere (alle UDI-brukere)

- Eksterne sluttbrukere/partnere (PIT, UNE, UD, IMDi), samt system- og driftsleverandører

«Henvendelse»: Alle typer forespørsler i et Service Management system (hjelp, feil, endring, bestilling, etc.).

«Operatør»: En som behandler henvendelser i Service Management-systemet.

«Løsningen»: Fellesbetegnelse på den fullstendige tjenesten som leveres.

Nr.	Krav	Kategori	Vekt (1-5)	Kommentar/Redegjørelse
	Maksimal verdiramme i denne anskaffelsen er NOK 15 000 000 eks. mva. Grunnlaget for vurderingen av verdirammen er utregnet totalpris for «Fastpris etablering» (Tabell 1) + «Totalverdi for avtalens 7 år» (Tabell 2), se Bilag 6. Pris for «Ekstra timer konsulentbistand» (Tabell 3) medregnes ikke i anskaffelsens maksimale verdiramme. Tilbud som overstiger maksimal verdiramme vil kunne bli avvist.	O
1. Generelle krav til løsningen
1.0	Leverandør bes vedlegge en arkitekturbeskrivelse/skisse for å gi Kunden et komplett oversiktsbilde over løsningen som tilbys.	O
1.1	Kunden skal gis tilgang til en demoversjon av løsningen sammen med en forklarende veiledning. Dette til bruk for evaluering av løsningen. Demoversjon skal tilgjengeliggjøres online som en webside.	O/R
1.2	Løsningen skal tilbys som en Software as a Service-løsning (SaaS).	O
1.3	Leverandør skal tilby forvaltning og support av løsningen.	O
1.4	Leverandøren bør ha en god og effektiv løsning for support og vedlikehold, optimalisering, kunderettet knowledge-base, online brukerforum eller lignende. Tilbudt løsning bør oppdateres jevnlig. Oppdatering bør skje med	B/R	3

	minst mulig nedetid for Kundens brukere.
1.5	Løsningen skal ha innebygget støtte for prosesser i ITIL v.3 eller høyere.	O/R
1.6	For prosessområdene Service Transisjon og Service Operasjon bør det tilbys ITIL v.4	B/R	3
1.7	Løsningen bør tilby raskest mulig responstid (0,1-1 sek.) på følgende: pålogging/ SSO, lagring av ny sak og ved relasting/oppdatering av skjermbilde ved endring på underliggende data.	B/R	5
1.8	Tilbudt løsning bør kunne vise oppdatert informasjon fortløpende, uten at operatør mister påbegynt arbeid.	B/R	2
1.9	Løsningen skal være på norsk (bokmål) og skal håndtere norsk tegnsett.	O
1.10	Den enkelte bruker bør som alternativ kunne velge engelsk.	B	2
1.11	Produktet som leverandørens løsning er basert på skal ikke ha en besluttet EOL-dato eller EOS- dato fra produsenten eller leverandøren.	O
1.12	Oppgraderinger av standardproduktet skal ikke påvirke konfigurert brukergrensesnitt.	O
1.13	Løsningen bør ha funksjoner for å integrere AI-teknologi for implementerte prosesser.	B/R	1
1.14	Web-basert brukergrensesnitt (for innmelding og behandling av henvendelser) skal ha støtte for følgende nettleserteknologier: På Windows 10/11: Som et minimum skal det benyttes Google Chrome, MS Edge. På Mac, IOS: Safari Android: Chrome	O
1.15	Løsningen bør ha funksjoner for modellering og visualisering av prosessene som er implementert. (Kundens foretrukne notasjon for modellering av prosesser er BPMN).	B/R	2

Side 3 av 21

1.16	Løsningen bør kunne stoppe tilgang for ulisensierte brukere.	B/R	5
1.17	Lisensavtale som er en del av løsningen, bør være underlagt norsk lov.	B	2
1.18	Løsningen bør ha innbygget funksjon for håndtering av sertifikat management i systemet.	B/R	2
1.19	Løsningen bør tilfredsstille krav til universell utforming iht. WCAG 2.1	B/R	2
1.20	Løsningen skal ha mulighet for å sette opp automatiske arbeidsflyter. For eksempel godkjenningsprosesser knyttet til det at vi har anledning til å lage/sette opp egne arbeidsflyter for ulike SOP`er (Standard operational prosecure) for smidige team. Dvs. enkle endringer med kort løp men som likevel krever en form for offisiell godkjenning og varsling.	O/R
2. Regulatoriske krav
2.1	Leverandøren skal håndtere nødvendige endringer i løsningen ved endringer i gjeldende norske og EU/EØS-lover, forskrifter og forskriftskrav som påvirker bruken av den tilbudte løsningen.	O
2.2	Leverandøren skal bekrefte at løsningen til enhver tid skal tilfredsstille alle gjeldende krav som er regulert av norsk lov.	O
3. Arkitekturkrav
3.1	Løsningen bør følge arkitekturprinsippene i UDI.	B/R	3
3.2	Løsningen skal ha IPv6 implementert og aktivert. Brukeren skal kunne benytte løsning der kun IPv6 er tilgjengelig. Dvs. at alle elementer og støtteelementer herunder DNS etc. må støtte IPv6.	O
3.3	Løsningen bør ha funksjonalitet for import og eksport av strukturerte data, gjerne via et API. Et behov er å kunne synkronisere mot Kundens underleverandørers CMDB i systemet.	B/R	2
3.4	Løsningen skal støtte HTML5 i brukergrensesnitt, samt i	O

	tilpasninger i løsningen som er utviklet særskilt for Kunden.
3.5	Løsningen skal ha en exit strategi for å eksportere data.	O
3.6	Løsningen bør ha en exit-strategi som krever minst mulig arbeid for Kunden.	B/R	3
3.7	Løsningen skal kunne tilby flere separate driftsmiljøer. Det skal kunne skilles mellom test og produksjon. Utvalg av konfigurasjonsdata fra ett driftsmiljø skal enkelt kunne overføres til et annet miljø.	O
3.8	Løsningen skal ha mulighet til å importere og eksportere data i standard format (minimum REST, csv-fil, og database).	O
4. Integrasjoner
4.1	Løsningen skal benytte seg av godkjente, ferdiglagde integrasjonsløsninger (plugins) for integrasjon med andre IT- løsninger gjennom et standardisert API. Som et minimum skal løsningen integreres med Azure DevOps, Azure AD, ServiceNow og Microsoft Outlook e-post.	O
4.2	Løsningen skal tilby integrasjonsstøtte for webtjeneste (ReST)	O/R
4.3	Løsningen bør kunne integreres mot flest mulig andre Service Management systemer.	B/R	5
4.4	Løsningen bør kunne støtte alternative kanaler for innmelding og oppfølging/behandling av henvendelser, f.eks. e-post, Teams, chat, osv.	B/R	3
4.5	Løsningen bør automatisk lagre all kommunikasjon i en henvendelse, uavhengig av kanal for innmelding.	B	2
4.6	Kunden ønsker en løsning som er godt uttestet mot Azure Devops når det gjelder håndtering av endringer via Azure Devops, slik at det er etablert en god «beste praksis» for denne integrasjonen.	B/R	3
4.7	Løsningen bør kunne tilby enveiskommunikasjon med InTune.	B	3

4.8	Løsningen bør ha mulighet til å hyperlenke mot andre knowledge management systemer og systemdokumenter, for eksempel Ulf-Wiki.	B/R	3
4.9	Løsningen bør støtte SCIM for bruker-provisjonering og deprovisjonering ifra UDIs IDP (Azure AD).	B	3
4.10	Løsningen bør kunne integreres mot DFØ-systemer/ bestilling til betaling (UNIT4).	B/R	2
5. Autentiseringskrav
5.1	Alle brukere interne og eksterne inkl. leverandører skal logge inn via respektive IDP’r og det skal benyttes SSO via Azure AD, eller evt. andre IDP’er via åpen ID Connect/SAML2.0	O/R
5.2	Løsningen skal kunne brukes fullt ut på klientutstyr uten å kreve forhøyede rettigheter i operativsystemet.	O
5.3	Løsningen skal aldri lagre eller overføre passord i ren tekst.	O
5.4	Alle brukerkontoer skal være personlige, inkludert administratorkontoer.	O
6. Moduler/Prosesser
6.1 Generelle krav
6.1.1	Løsningen skal ha støtte for Service Management-prosesser iht. ITIL-rammeverket. Basiskonfigurasjon for disse prosessene skal være tilgjengelig "out of the box" (OOTB), med muligheter for tilpasninger etter behov. Løsningen skal som et minimum inkludere støtte for følgende ITIL- prosesser: - Incident Management - Problem Management - Service Request Management - Change Management - Knowledge Management - Asset and Configuration Management	O
6.1.2	Løsningen skal konfigureres for å også kunne tas i bruk av andre enheter i organisasjonen utenfor	O

	IT-avdelingen, som i HR-enheten og i Dokumentsenteret.
6.1.3	Løsningen bør kunne tilby et tilpasset webbasert grensesnitt eller en app for mobile enheter.	B/R	5
6.1.4	Løsningen skal tilby konfigurerbare, interaktive dashboards/views for visning av oversikter og statistikk.	O
6.1.5	Kunden skal selv kunne tilpasse løsningen etter egne behov, uten å ha kodekunnskap. Som et minimum skal Kunden, kunne gjøre følgende selv: - gjøre endringer i meny-valg - endringer i kategoriserings- og assignment alternativer - kunne lage, endre eller slette maler som brukes i prosessområdene - administrere roller og tilganger i verktøyet - lage/endre/slette katalogelementer - endre SLA-betingelser for saksbehandling og tjenester	O
6.1.6	Løsningen bør ha støtte for oppgave- og prosessautomatisering, orkestrering av saksflyt og «auto fulfillment».	B/R	3
6.1.7	Løsningen skal dokumentere responstid og løsningstid på henvendelser.	O/R
6.1.8	Løsningen bør kunne lagre en “kladd”-melding automatisk.	B/R	2
6.1.9	Tilbudt løsning skal ha en funksjonalitet for å generere automatisk svar til innmelder/ sluttbruker ved faseendringer/ statusoppdatering i henvendelser.	O
6.1.10	Løsningen skal ha en del pre- definerte svar-maler som Kunde kan redigere og tilpasse til eget behov, samt mulighet til å lage nye maler.	O/R
6.1.11	Løsningen skal ha mulighet til å relatere/knytte/linke sammen forskjellige typer henvendelser.	O
6.1.12	Tilbudt løsning skal ha funksjonalitet for å merke henvendelser med sensitive opplysninger annerledes slik at	O/R

Side 7 av 21

	UDI kan sortere/ filtrere slike henvendelser etter behov.
6.1.13	Løsningen bør kunne foreslå løsning for alle typer henvendelser ved å vise til relevante kunnskapsartikler og lignende problemer, når en henvendelse opprettes.	B/R	3
6.1.14	Løsningen bør gi mulighet for å omprioritere henvendelser, dersom noe haster mer.	B/R	3
6.1.15	Løsningen bør enkelt kunne konvertere en henvendelse til en annen type sak innen ITIL- prosess og beholde historikken. For eksempel konvertere fra request til incident, fra incident til change ved å beholde historikken i henvendelsen.	B/R	3
6.1.16	Løsningen skal ha funksjonalitet for å kunne filtrere henvendelser etter ulike typer miljøer: staging, AT (akseptansetestmiljø), produksjon- og utviklingsmiljø.	O
6.1.17	Løsningen skal ivareta rollebasert tilgangsstyring som gir rettigheter til å opprette, sette opp/konfigurere, endre, tilpasse og fjerne skjemaer for ulike type henvendelser.	O
6.1.18	Løsningen bør som et minimum ha 3 kategorinivåer. Kunde bør ha mulighet til å designe/ bestemme antall kategorinivåer selv.	B/R	2
6.2 Servicedesk-portal (webside hvor brukere melder inn saker)
6.2.1	Løsningen skal inneholde en fullt konfigurerbar servicedesk-portal. F.eks. for bestilling av varer, tjenester, utstyr og brukertilganger, hvor alle skjemaer kan tilpasses etter behov.	O
6.2.2	Servicedesk-portalen skal tilfredsstille krav til universell utforming iht. WCAG 2.1 (som et minimum av kategori AA).	O
6.2.3	Tjenestekatalog i tilbudt løsning skal kunne konfigureres og forvaltes av Kundens eget personell.	O
6.2.4	Innholdet i tilbudt tjenestekatalog bør kunne spesifiseres på norsk, og presenteres i tjenesteportalen	B/R	2

	med det språket som samsvarer med den enkelte brukers språkprofil. Det bør foreligge mulighet for norsk og engelsk.
6.2.5	Løsningen bør tillate oppretting av en rollebasert visning av tjenestekatalog.	B	1
6.2.6	Løsningen bør ha mulighet til å publisere varsling «på tvers» om en stor feil eller henvendelse som påvirker alle.	B/R	2
6.2.7	Løsningen bør kunne identifisere de mest brukte valgene (items) og foreslå disse til sluttbrukeren i portalen.	B/R	1
6.2.8	Løsningen bør ha kunnskapsbasen tilgjengelig i sluttbrukerens portal.	B/R	3
6.2.9	Løsningen bør ha mulighet/ funksjon for å gjenåpne eller duplisere automatisk en henvendelse fra servicedesk- portalen, som tidligere er lukket.	B/R	2
6.2.10	Løsningen bør kunne publisere lenke til ekstern webshop (produktkatalog) i servicedesk- portalen.	B/R	2
6.2.11	Tjenestekatalog bør kunne opprettes for flere fagområder (f.eks. for fagsystemer, vaktmestertjenester og infrastruktur). Under hvert fagområde bør hver tjeneste ha mulighet for minimum 2 underliggende nivåer (1 nivå er ikke tilstrekkelig for å dekke Kundens behov).	B/R	3
6.3 Incident Management modul
6.3.1	Løsningen bør ha dataetiketter (felter) for: innmelder og kontaktperson (kan være forskjellige), tjeneste og CI; kategori og underkategori, status, tildelingsgruppe og operatør (den som behandler saken); leverandør og referansenummer fra leverandør, miljø, utvalg av type feil (A, B, C), impact, ugrency og prioritet, tittel og beskrivelsesfelt.	B/R	3
6.3.2	Løsningen skal ha oppsett av feilrettingstider for A, B og C-feil (eller tilsvarende) basert på SLA- bestemmelser.	O

6.3.3	Løsningen bør ha mulighet for å kategorisere en Incident sak som “problem-kandidat”.	B/R	3
6.3.4	Løsningen bør ha en logikk for å kunne sette opp prioritering, automatisk kategorisering (CI) av henvendelser og direkte tildeling.	B/R	2
6.3.5	Løsningen skal ha mulighet for å endre prioritet for en henvendelse underveis i saksgangen og etter lukking.	O
6.3. 6	Løsningen skal ha en funksjon for automatisk lukking av løste henvendelser etter X antall dager (Kunde bestemmer antall dager).	O
6.3.7	Løsningen bør ha god funksjonalitet for ekstra rask opprettelse og håndtering av A- kritisk feil, sammenlignet med øvrige kategorier feil.	B/R	3
6.3.8	Løsningen bør ha funksjonalitet for at operatør kan sette seg selv som inaktiv i systemet ved f.eks. ferie eller fravær. Det bør være mulighet for at lederen kan overstyre.	B/R	3
6.4 Problem Management modul
6.4.1	Løsningen skal kunne relatere løste problemsaker mot CI i verktøyets CMDB og de dokumenterte løsningene som "Known error" for den aktuelle CI.	O
6.4.2	Registrerte incident skal knyttes til en eller flere problem-saker (henvendelser), eller omvendt.	O
6.4.3	Løsningen bør ha mulighet til å dele opp en problem-sak i flere oppgaver.	B/R	2
6.4.4	Løsningen bør kunne foreslå automatisk opprettelse av kunnskapsartikler fra løste problemer.	B	2
6.5 Service Request Management modul
6.5.1	Løsningen bør kunne gi mulighet for å styre køen både manuelt og automatisk.	B/R	3
6.5.2	Løsningen bør ha funksjonalitet for å kunne tilpasse godkjenningsprosedyre.	B/R	3
6.5.3	Løsningen bør tillate at en henvendelse splittes opp i flere oppgaver som tilordnes til flere grupper/operatører.	B/R	5

6.6 Change Management modul
6.6.1	Løsningen skal ivareta oppsett, konfigurasjon av change- prosesser (faser) for både fossefall og agile metodikk.	O
6.6.2	Løsningen skal ha kategorier for håndtering av Standard, Normal og Emergency endringer.	O
6.6.3	Løsningen skal kunne generere endringskalender (oversikt over alle planlagte endringer) automatisk.	O
6.6.4	Løsningen bør kunne synliggjøre endringskalender i servicedesk portalen, slik at den også er tilgjengelig for autoriserte bestillere uten systemtilgang til verktøyet.	B/R	2
6.6.5	Løsningen bør kunne gi oversikt over tjenester som berøres av en endring.	B/R	3
6.6.6	Løsningen bør kunne oppdage konflikter og varsle dersom endringer påvirkes av andre planlagte endringer/aktiviteter.	B/R	3
6.6.7	Tilbudt løsning skal ha innbygget funksjon for å synligjøre risiko ved implementering av en endring.	O
6.6.8	Løsningen skal ha en CAB- funksjon for å planlegge, administrere og styre endringer knyttet til kalender, som viser planlagt innføring.	O
6.6.9	Løsningen bør kunne sende ut varsel direkte fra change- modulen til berørte brukere ifm. ustabilitet og nedetid på tjenester ved gjennomføring av endringer	B/R	3
6.6.10	Løsningen bør kunne vise samlet oversikt over timer, i en change som håndteres av en ressurs eller ulike involverte. Tjenesten bør ha to type tidsregistreringsfelt: estimat og faktisk forbruk.	B/R	2
6.6.11	Løsningen bør ha funksjonalitet hvor kunden selv enkelt kan fjerne, endre eller konfigurere nye standard change etter behov.	B	3
6.6.12	Løsningen bør ha mulighet til å konfigurere rettigheter og synliggjøring til enkelte felter og vedlegg i change manager modul	B/R	1

	(f.eks. at antall konsulenttimer fra en leverandør ikke synliggjøres for en annen leverandør).
6.7 Knowledge Management modul
6.7.1	Tjenesten skal tilby en kunnskapsbase som kan forvaltes og oppdateres av Kunden.	O
6.7.2	Løsningen skal ha funksjonalitet for å revidere og godkjenne kunnskapsartikler før de publiseres.	O
6.7.3	Løsningen bør gi mulighet til å opprette/ publisere kunnskapsartikler for ulike grupper basert på brukerkriterier, f.eks. som avdeling.	B	2
6.7.4	Løsningen bør kunne sende varsel om revisjon av kunnskapsartikler.	B	1
6.8 Asset and Configuration Management modul
6.8.1	Tjenesten bør kunne tilby grafisk visning for en CI, applikasjon eller forretningstjenester CI-en støtter.	B/R	1
6.8.2	Systemet bør ha mulighet til å hyperlenke mot andre CMDB og systemdokumentasjon.	B	2
6.8.3	Systemet bør kunne vise oversikt over aktuelle leverandører eller ressurser/personer som har drifts- og oppfølgingsansvar for berørte systemer (CI owner).	B	2
7.Service Level Agreement
7.1	Tilbudt løsning skal ha en implementert SLA-funksjon.	O
7.2	Tjenesten bør ha mulighet til å tillate oppsett av flere SLA, OLA, KPI og understøttekontrakter (UC).	B/R	3
7.3	Tjenesten skal ha mulighet til å definere start-, pause-, stopp- for en SLA, og det skal være mulig å endre dette underveis i saksgangen.	O
7.4	Tjenesten bør ha en visning/et dashboard som gir innsikt i alle SLA-er per henvendelsestype per leverandør/kontrakt.	B	3
7.5	Løsningen skal gi automatisk SLA-baserte frister og sende påminnelse til saksbehandler hvis SLA-fristen nærmer seg og saken fortsatt ikke er løst.	O

7.6	Løsningen bør vise (rollebasert visning) SLA/OLA/KPI/UC som har gått over tidsfristene eller hvor fristene nærmer seg.	B	3
7.7	Løsningen bør ha funksjonalitet for å innhente respons fra sluttbrukere på løste saker.	B/R	1
7.8	Løsningen bør tilby automatisk varsling (for eksempel e-post eller andre kanaler) ved brudd på SLA- tid.	B/R	3
8. Brukergrensesnitt
8.1	Sluttbrukere skal melde inn henvendelser via servicedesk portal.	O
8.2	Løsningen bør ha en funksjon hvor førstelinje-support kan opprette en sak som meldes inn via telefon, på en enkel måte. For eksempel en egen knapp som genererer en sak basert på telefonsamtale.	B/R	1
8.3	Løsningen skal ha et konfigurerbart dashboard til eget behov/ansvarsområde både for interne brukere hos Kunden, samt for eksterne partnere (styres av rollebasert tilgang).	O
8.4	Løsningen bør vise ulike rollebaserte visninger (For eksempel vise “leder view” og “bruker view”).	B/R	2
8.5	Løsningen skal gi en status/ oversikt i servicedesk portalen over egne henvendelser iht. utvalgte kriterier og rettigheter. Som et minimum må brukeren se egne innmeldte saker, arbeidsflyt i sak, status og framdrift, relaterte feil eller endring som knyttes til den innmeldte saken og status.	O
9. Rapportering
9.1	Løsningen bør ha gode rapporteringsmuligheter med aktive (klikkbare) rapporter for alle tjenester og moduler i løsningen som enkelt kan tilpasses til behov, basert på roller og kriterier. Gjerne pre- definerte maler.	B/R	3
9.2	Rapporteringsfunksjon skal ha et konfigurerbart dashboard med rollebasert tilgangsstyring.	O

9.3	Løsningen bør kunne støtte ulike rapporttyper og trendanalyser.	B/R	2
9.4	Løsningen bør gi mulighet for å måle leveransene og rapportere på ulike SLA og OLA, herunder: - Tidsbruk per sak - Svartid, løsningstid og responstid pr. henvendelse - Gjennomløpstid for en sak (tiden som brukes fra en sak innmeldes til den blir løst). - Antall henvendelser som løses direkte av servicedesk eller onsite support (1.linje) - Antall saker som må eskaleres til 2. og 3.linje - Antall saker som løses over en gitt periode - Hvor lang tid sakene har gått over SLA (delta)	B/R	5
9.5	Tilbudt løsning bør ha en funksjon for å sette opp automatisk utsendelse av rapporter.	B	1
9.6	Alle tidligere rapporter bør være søkbare i systemet, slik at man kan søke på en bestemt dato/tidspunkt og få opp aktuelle rapporter.	B	1
10. Tilgangsstyring
10.1	Løsningen skal ha ferdig definerte roller og tilganger som dekker behov OOTB (out of the box) for alle vesentlige prosesser og brukernivåer. Tjenesten skal også ha støtte for tilpasning og opprettelse av slike roller og tilganger.	O
10.2	Løsningen skal tillate at en bruker kan ha flere roller og veksle mellom moduler, uten ekstra pålogging.	O
10.3	Tilganger skal kunne tildeles automatisk basert på importerte attributter fra f. eks AD integrasjon eller lignende.	O
10.4	Løsningen bør ha støtte for konfigurering av felter og andre typer endringer av brukerprofiler.	B/R	2
10.5	Løsningen bør ha mulighet for at Kunden selv kan styre/ administrere innsyn/ rettigheter i systemet for ulike moduler (eks. Sette opp ulike rettigheter for	B/R	5

	brukere, ledere, interne og eksterne).
11. Backup og restore
11.1	Løsningen bør ha en god og hensiktsmessig løsning for backup og restore.	B/R	5
11.2	Løsningens backup- og restore- plan bør kunne gjenspeile Leverandørens tjenestenivåavtale (tilgjengelighet og oppetid).	B/R	3
12. Testmiljø og testing
12.1	Løsningen skal tilby testmiljø og brukerkontoer til dette uten ekstra kostnad.	O
12.2	Løsningen og alle fremtidige endringsversjoner, skal testes i et testmiljø og deretter kan etablering ta plass i produksjonsmiljø etter godkjent akseptansetest.	O
12.3	Løsningen bør ha funksjoner for automatisert testing av ny funksjonalitet før ny funksjonalitet kan implementeres i et produksjonsmiljø.	B/R	1
12.4	Leverandøren bør tilby en god «beste praksis»-testmetodikk for løsningen.	B/R	3
12.5	Leverandør bør kunne bruke Azure DevOps som verktøy for effektiv oppfølging fra Kunde.	B/R	3
12.6	Plattformen bør tilby funksjoner for sandboxing i testmiljø der hvert enkelt produktteam kan teste ny funksjonalitet isolert fra andre brukere.	B	3
12.7	Testprosedyrene skal omfatte testing av Universell Utforming iht. krav WCAG 2.1 (xxxxx://xxx.xxxxxxxxxx.xx/xxxxxxx rk/testprosedyrar-nettstader/709)	O
12.8	Leverandør skal sammen med Kunde utarbeide exit-kriterier med akseptansetest.	O

Opsjon på Prosjekt- og Porteføljestyringsmodul (frivillig å tilby)

Generelle krav i øvrig kravspesifikasjon gjelder kun for denne opsjonen så fremt det er angitt særskilt.

Prosjekt- Porteføljestyringsmodul (opsjon)		Kategori	Vekt	Kommentar/ Redegjørelse
1.	Modulen skal ha funksjonalitet for å følge opp prosjekter, program og portefølje iht. AXELOS-rammeverk for porteføljestyring (MoP, P3O og MSP).	O
2.	Modulen bør ha god funksjonalitet for analyse av prosjektporteføljen.	B/R	2
3.	Modulen bør kunne lage hensiktsmessige periodiske rapporter basert på innlagt rapportering fra prosjektledere, scrum-mastere og programledere.	B/R	2
4.	Modulen bør kunne hente ut en samlet oversikt over allokerte ressurser per prosjekt/portefølje.	B	1
5.	Modulen bør kunne følge metodikken til Prince2/ Prince2 Agile.	B	2
6.	Modulen skal vise relasjon mellom prosjekt, innmeldt endring eller incident/problem som knyttes til prosjektet.	O
7.	Modulen bør kunne hente ut regnskapsinformasjon og tidsregistrering fra DFØ- systemer.	B/R	2
8.	Løsningen skal oppfylle krav nr. 6.1.4 og 9.2.	O
9.	Løsningen bør oppfylle krav nr. 9.1.	B/R	3

Avtalens punkt 3.4 Dokumentasjon og opplæring

Dokumentasjon		Kategori	Vekt	Kommentar/ Redegjørelse
1.	Leverandør skal levere all dokumentasjon på norsk og denne skal	O

	oppdateres etter hver ny oppdatering/endring.
2.	Leverandøren skal gi tilgang til fullstendig og oppdatert dokumentasjon av løsningen, inkludert: 1. Generell dokumentasjon av løsningen og overordnede arkitektur med en liste over alle tilpasninger. 2. Funksjonell dokumentasjon av Løsningen (konfigurasjon, funksjonell design og tilpasninger). 3. Sluttbrukerveiledning, Superbrukerhåndbok og prosessdesign / konfigurasjonsveiledning. 4. Dokumentasjon for kundedrift og administrasjon. 5. Teknisk dokumentasjon for eventuelle tilpasninger og integrasjoner.	O
3.	Leverandøren skal sørge for oppdatert opplæringsmateriell gjennom hele kontraktens løpetid, i henhold til gjeldende versjon av løsningen.	O

Avtalens punkt 3.5 Oppgradering/vedlikehold av tjenesten etter Leveringsdag

Nr.	Krav	Kategori	Vekt	Kommentar/ Redegjørelse
1. Utvikling
1.	• Kunden skal bli varslet om, og få god opplæring i, nye oppdateringer og muligheter i tjenesten som vil inngå i avtalen (f.eks. ved brukerveiledninger og/eller kurs). • Kunden skal informeres i god tid om større endringer i alle miljøer før de oppstår, f.eks. via nyhetsbrev, minimum 14 kalenderdager før endringen aktiveres. • Kunden skal også ha muligheten til å få tilgang på en demoversjon for å teste ny funksjonalitet før det kommer på live-versjonen. • Leverandør står for all patching/vedlikehold. • Oppgraderinger av systemene skal skje innen rimelig tid.	O/R

Avtalens punkt 3.6 Ytterligere utvikling etter Leveringsdag

Nr.	Krav	Kategori	Vekt	Kommentar/ Redegjørelse
Ytterligere utvikling
1.	Kunden skal ha mulighet til å komme med tilbakemeldinger og forbedringsforslag som kan implementeres ved behov. Leverandøren skal ha en kontaktperson for single-point-of- contact. Statusmøter avholdes 2 ganger i året.	O
2.	Beskriv produsentens Release Policy for produktet som løsningen baseres på. Antall planlagte release pr. år og hvor mange av disse som kan medføre ny funksjonalitet, behov for regresjonstester m.m. Beskrivelsen bør være egnet til å sikre at man unngår uforutsette hendelser som påvirker Kunden.	B/R	2
Versjonskontroll
3.	Det bør foreligge gode rutiner for løsningen som sikrer en stabil og god tjeneste (unngåelse av distrupsjonsendring).	B/R	3
4.	Løsningen bør ha en versjonskontroll av kundespesifikk konfigurasjon.	B	3

Avtalens punkt 6.1 Informasjonssikkerhet

Sikkerhetskrav		Kateg ori	Vekt	Kommentarer/ Referanse
1.	Alle sikkerhetskravene gjelder både for hovedleverandør og eventuelle underleverandører.	O
2.	All kommunikasjon skal foregå over HTTPS, minimum TLS 1.2.	O
3.	All kommunikasjon skal foregå over HTTPS minimum TLS 1.3 innen 01.01.2024.	O
4.	Løsningen bør ha gode funksjoner for sikker, kontrollert og sentralisert tilgang til konfigurasjon og administrasjon av det	B/R	2

	grunnleggende oppsettet for sikkerhet i prosessløsningen for Kunden.
5.	Leverandøren skal inngå en databehandleravtale i henhold til Xxxxxxx mal for denne, ref. vedlagt SSA-L bilag 10.	O
6.	Leverandøren skal ved behov gi etterspurt informasjon for Kundens egen risikovurdering og konsekvensutredning.	O
7.	Leverandør skal levere et Cloud Security Alliance Consensus Assessment Initiative Questionnaire (CAIQ) (CAIQ) v4 xxxxx://xxxxxxxxxxxxxxxxxxxxx.xxx/xxxxxxxxx/xx oud-controls-matrix-v4/	O
8.	Leverandøren og eventuelle underleverandører bør levere tjenesten i samsvar med ISO 2700, ISO 27017 eller ISO 27018.	B/R	2
9.	Løsningen skal ha logger som sier hvem som er logget på, hva som er gjort og når. Tilgangene til logger skal kun være tilgjengelig for autoriserte personer.	O
10.	Løsningen skal ha funksjonalitet for ivaretagelse av personvern i innmeldte henvendelser. Som et minimum: - Informasjon til den registrerte om behandlingen av personopplysninger - Funksjonalitet for innsyn, retting og sletting - Funksjonalitet for anonymisering/sladding i innmeldte henvendelser	O
11.	Ved brudd på personopplysningssikkerheten skal leverandør varsle UDI om bruddet innen 24 timer etter bruddet oppdages, og i tråd med personvernforordningen art 33 nr. 3.	O
12.	Løsningen bør ha funksjonalitet for automatisk sletting av innmeldte henvendelser basert på egendefinerte slettefrister.	B	2
13.	Leverandøren av skytjenesten bør ha prosess for sikkerhetsopplæring av eget personell ifm. den aktuelle løsningen som leveres. Prosessen bør som et minimum sikre systematisk og jevnlig opplæring av personell i hvordan de skal håndtere aktuelle systemer og informasjon på en god og sikker måte.	B/R	3
14.	Leverandøren bør gi dokumentasjon på Disaster Recovery Plan som også	B/R	3

	inkluderer Security Event Management og undersøkelsesprosesser. Dokumentasjonen bør vise at leverandøren har gode prosesser i slike kriser.
15.	Leverandøren skal bekrefte at det ikke vil bli flyttet eller kopiert data fra Kundens profil uten at dette er vurdert og godkjent av Xxxxxx.	O
16.	Personopplysninger skal kun behandles i EU/EØS. Leverandør og leverandørens underleverandører, skal ikke overføre eller på annen måte utlevere personopplysninger til tredjestater eller internasjonale organisasjoner.	O
17.	Tilstedeværelse av ansatte hos leverandør og alle underleverandører som skal drifte og vedlikeholde en skyløsning for Kunde skal være innenfor EU/EØS.	O
18.	Forhold knyttet til eierskap og drift av datasentre og infrastruktur, samt sikkerhetstiltak og sikkerhetsstandarder bør kunne dokumenteres på en oversiktlig måte. De aktuelle forholdene bør være egnet for å gi god sikkerhet i leveransen.	B/R	3

Avtalens punkt 6.2 Personopplysninger

Kundens databehandleravtale er vedlagt og skal benyttes for Leveransen.

Avtalens punkt 7.1 Partenes rettigheter

[Eventuell tekst]

Avtalens punkt 8 Rekonstruksjon av data

[Eventuell tekst]