Instruktion til tilbudsgiver

Bilag 07.2.A - Ydelser og Servicemål

FLIS Genudbud

Nærværende bilag indeholder en beskrivelse af de Ydelser, som Leverandøren skal levere i henhold til Driftskontrakten, og Servicemålene herfor, hvor Leveran- døren har det samlede leveranceansvar for Infrastrukturdrift, Applikationsdrift og Applikationsvedligehold.

Nærværende bilag skal udfyldes af Tilbudsgiver, jf. nedenstående retningslinjer.

Tilbudsgiver skal som del af sit tilbud følge og besvare instruktioner, som er mar- keret med […]. For nærværende bilag betyder det, at Tilbudsgiver skal:

• angive kontaktperson til rapportering af Incidents, jf. punkt 1

• angive kontaktperson til Service Desk, jf. punkt 10.1.

Bilaget skal ikke herudover udfyldes af Tilbudsgiver, idet Tilbudsgivers besvarelse af øvrige dele af bilaget skal ske ved at udfylde bilag 7.2.A.1 i henhold til instruk- tionerne angivet i bilag 7.2.A.1.

Tilbudsgivers besvarelse skal indsættes med tydelig markering, f.eks. med farvet skrifttype, så det er klart for KOMBIT, hvilke dele af bilaget der er besvaret af Til- budsgiver. Anvendelse af ændringsmarkering er reserveret til Tilbudsgivers even- tuelle forbehold.

Tilbudsgivers eventuelle forbehold til bilag 7.2.A anføres i forbeholdslisten og skrives ind med ændringsmarkering i selve bilaget i overensstemmelse med ud- budsbetingelserne.

Det bemærkes, at Kontrakten uden bilag og Driftskontraktens bilag 7.2, 7.3 og

7.4 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor, jf. udbudsbetingelserne. Tilbudsgiver skal derfor sikre, at eventuelle forbehold til bi- lag 7.2.A ikke udgør et forbehold overfor Kontrakten uden bilag og Driftskontrak- tens bilag 7.2, 7.3 og 7.4.

Det bemærkes endvidere, at følgende dele af bilag 7.2.A udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor:

• Punkt 2.3

• En del af punkt 1

• Punkt 1 til og med Punkt 4.6.2

• Punkt 1 med underpunkter

• Punkt 13 med underpunkter

• Punkt 14 med underpunkter

• En del af punkt 18.1

• Punkt 18.5

• Punkt 19 med underpunkter

Om betydningen og vurderingen af Tilbudsgivers besvarelse af instrukser og eventuelle forbehold til bilaget henvises til udbudsbetingelserne.

Indholdsfortegnelse

KAPITEL I Indledning 6

1 Indledning 6

2 Generelle bestemmelser 6

2.1 ITIL 6

2.2 Generelt om Leverandørens Ydelser 9

2.3 Måleperioder 9

2.4 Kritiske Servicemål og Kritiske ikke-månedlige Servicemål 10

2.5 Tvister om Servicemål 10

KAPITEL II Service Operation 11

3 Introduktion til Service Operation 11

4 Incident Management 11

4.1 Generelle krav til Leverandørens Incident Management 11

4.2 Indrapportering af information om Incidents 12

4.3 Prioritering af Incidents 13

4.4 Kategorisering af Integrationer til incidentprioritering 15

4.5 Kategorisering af Batchkørsler til Incidentprioritering 17

4.6 Løsning af Incidents 18

4.7 Servicemål for Incident Management 20

4.8 Kontaktperson til KOMBITs rapportering af Incidents 22

4.9 Eskalering til KOMBIT samt orientering om Incidents til Brugere mf. 22

4.10 Afslutning på Incident Management processen 24

5 Monitorering, Event og Log-Management 24

5.1 Events 25

5.2 Logning 25

6 Driftsafvikling af Batchkørsler 26

6.1 Indplacering af Batchkørsler 27

6.2 Servicemål for Batchkørsler 27

7 Ind og Udlæsning af Data og Datapakker 28

7.1 Indlæsning af Data 28

7.2 Udlæsning af Data 28

8 Backup og Restore 29

9 Problem Management 30

9.1 Problems 30

9.2 Ydelser under Problem Management 31

9.3 Prioritering af Problems 32

9.4 Problems, som Leverandøren er ansvarlig for 33

9.5 Problems, som Leverandøren ikke er ansvarlig for 33

9.6 Servicemål for Root Cause Analyser 33

10 Service Desk 34

10.1 Supportorganisation 34

10.2 IT Service Management system 35

10.3 Systemets dertil indrettede hjemmeside 36

10.4 Servicemål for Service Desk 37

10.5 Dokumentation af henvendelser til Service Desk 38

11 Request Fulfilment 38

11.1 Indrapportering af information om Service Requests 39

11.2 Servicemål for Service Requests 39

12 Access Management 43

13 Servicemål for drift 44

13.1 Servicemål for Applikationsdrift 45

13.2 Servicemål for Infrastrukturdrift 46

13.3 Kombineret Tilgængeligheds Servicemål 47

13.4 Systemets brugeroplevede driftseffektivitet 47

13.5 Oversigt over Servicemål for Applikationsdrift og Infrastrukturdrift 47

14 Systemets svartider 48

14.1 Generelt om svartider 48

14.2 Modregning af svartid udenfor Systemet 49

14.3 Svartider for transaktioner i brugergrænsefladen 49

14.4 Kontrolmåling af svartider 53

KAPITEL III Service Transition 56

15 Introduktion til Service Transition 56

16 Change Management 56

16.1 Servicemål for Change Management 57

16.2 Risikovurdering af RfC 58

16.3 Dokumentation af RfC 58

17 Validation og test 58

18 Release and Deployment Management 59

18.1 Vedligeholdelse af System og Driftsmiljøe med ny Versionr 60

18.2 Vedligeholdelse af Systemet med 3.partsprogrammel 62

18.3 Vedligeholdelse af Integrationer 62

18.4 Sletning af data 63

18.5 Servicevinduer til vedligeholdelse 63

18.6 Plan for nye Versioner 64

19 Patch Management 65

19.1 Servicemål for Patch Management 65

20 Asset- og Configuration Management 67

21 Knowledge Management 67

KAPITEL IV Service Design 69

22 Introduktion til Service Design 69

23 Capacity Management 69

24 Availability Management 69

25 IT Service Continuity 70

25.1 Disaster Recovery plan 70

25.2 Disaster Recovery test 70

25.3 Disaster Recovery rapport 71

25.4 Afprøvning af redundante setup i Produktionsmiljøet 71

26 Information Security Management 71

26.1 Penetrationstest 73

26.2 Sikkerhedsrevisionserklæring 73

27 Supplier Management og Business Relations 74

28 Plan for og test af Systemets overdragelse til Infrastrukturdrift 74

29 Deltagelse i overdragelse af Infrastrukturdrift 75

30 Plan og test af overdragelse af Infrastrukturdrift og Applikationsdrift 76

31 Deltagelse i overdragelse af Infrastrukturdrift og Applikationsdrift 77

KAPITEL I INDLEDNING

1 Indledning

Nærværende bilag har til formål at beskrive krav til og Servicemål for Leverandørens drift og Ydelser relateret til Applikationsdrift, Applikationsvedligehold og Infrastrukturdrift, hvor Leve- randøren har det samlede leveranceansvar for disse tre Ydelser.

Dette bilag er opdelt i fire kapitler startende med dette indledende KAPITEL I, der indeholder indledning og generelle bestemmelser for Leverandørens Ydelser.

KAPITEL II indeholder krav og Servicemål til Leverandørens driftsafvikling samt Ydelser un- der Service Operation.

KAPITEL III indeholder krav og Servicemål til Leverandørens Ydelser under Service Transi- tion.

KAPITEL IV indeholder krav og Servicemål til Leverandørens Ydelser under Service Design. Det bemærkes, at bilag 7.2.A har forrang frem for bilag 7.2.A.1, jf. Kontraktens punkt 55.2.

2 Generelle bestemmelser

For Leverandørens Ydelser gælder generelt de i dette punkt 2 angivne bestemmelser og krav.

2.1 ITIL

Drift, vedligeholdelse og support skal håndteres i overensstemmelse med ITIL v3 (eller tilsva- rende).

I Driftskontrakten anvendes de i nedenstående tabel anførte begreber fra ITIL v3 i overens- stemmelse med disse begrebers overordnede forståelse i ITIL v3. Brugen af begreberne in- debærer således, at enhver proces eller opgave, der er relateret til det pågældende begreb efter ITIL v3, skal følges eller løses i henhold til ITIL v3 under Driftskontrakten, medmindre andet er angivet i bilag 7.2.A eller bilag 7.2.A.1.

Alle ITIL begreber benyttes med store forbogstaver. Såfremt Driftskontraktens anvendelse af begreberne, der er anført i tabellen nedenfor, afviger fra ITIL, er denne afvigelse beskrevet i tabellen.

Leverandøren skal sikre, at der i Dokumentationen og i øvrigt i enhver kommunikation mel- lem Parterne er klarhed og konsistens i begrebsanvendelsen fra ITIL v3, idet Leverandøren

dog ligeledes skal sikre konsistens med de fravigelser fra begrebsanvendelsen i ITIL v3, der fremgår af tabellen nedenfor.

ITIL begreb Standard ITIL v3 Beskrivelse af afvigelse fra standard ITIL Definition v3 definitionen
Access Management	Ja
Asset Management	Ja

ITIL begreb Standard ITIL v3 Beskrivelse af afvigelse fra standard ITIL Definition v3 definitionen
Availability Management	Ja
Backup	Ja
Capacity Management	Ja
Change	Ja
Change Advisory Board (CAB)	Ja, men med afvi- gelse	CAB behandler RfC som en del af Change Management processen og er beskrevet i bilag 7.2.G. Change Management behand- ler først RfC, når en Change er klar til at blive idriftsat. Prioritering og udvikling af en Change reguleres i henhold til Kontrakten.
Change Management	Ja, men med afvi- gelse	Change Management er den proces, som anvendes, når ændringer skal implemente- res i Driftsmiljøet. Change Management i Driftskontrakten rådgiver om ændringer, samt godkender idriftsættelsen af RfC. Pri- oriteringer af ændringer til Systemet, udvik- ling af ændringer, test af ændringer og Do- kumentation af ændringer er ikke en del af Change Management, men er beskrevet i Dokumentationen af RfC.
Configuration Item	Ja
Configuration Management	Ja
Configuration Management Database	Ja
Disaster Recovery	Ja
Emergency Change	Ja
Emergency Patch	Ja, men med afvi- gelse	Se punkt 19.
Event	Ja
Event Management	Ja
Exceptions	Ja
First-line Support	Ja, men med afvi- gelse.	I Driftskontrakten benyttes ordet 1st Level Support i stedet for First-line Support
Incident	Ja, men med afvi- gelse.	Incidents betyder enhver uplanlagt hæn- delse, som ikke er en del af normal drift af Systemet, og som forårsager eller kan for- årsage en driftsforstyrrelse eller en reduk- tion af kvaliteten af driften eller andre Ydel- ser eller fejl i et Configuration Item
Incident Management	Ja
Incident Record	Ja

ITIL begreb Standard ITIL v3 Beskrivelse af afvigelse fra standard ITIL Definition v3 definitionen
Information Security Mana- gement	Xx
IT Service Continuity	Ja
Knowledge Management	Ja
Known Error Database	Ja
Major Incident	Ja
Major Incident Manager	Xx
Monitoring (Monitorering)	Ja
Operation Incident	Ja
Patch	Ja
Patch Management	Ja
Problem	Ja
Problem Management	Ja
Problem Record	Ja
Release Management	Ja
Release and Deployment Management	Ja
Request for Change (RfC)	Ja
Request Fulfilment	Xx
Restore	Ja
Root Cause	Ja
Root Cause Analysis (Root Cause Analyse, RCA)	Ja
Second-line Support	Ja, men med afvi- gelse.	I Driftskontrakten benyttes ordet 2nd Level Support tilsvarende Second-line Support.
Security Incident	Ja
Service Design	Ja
Service Desk	Ja
Service Operation	Ja
Service Request	Ja
Service Transition	Ja
Standard Change	Ja
Supplier Management og Business Relations	Ja
Third-line Support	Ja, men med afvi- gelse.	I Driftskontrakten benyttes ordet 3rd Level Support tilsvarende Third-line Support
Workaround	Ja, men med afvi- gelse.	I Driftskontrakten benyttes ordet Omgåelse i stedet for Workaround

Tabel 1 ITIL begreber

2.2 Generelt om Leverandørens Ydelser

Som det fremgår af Driftskontraktens punkt 4.1, stilles der under Driftskontrakten en række

generelle krav til Leverandørens Ydelser. Det er således af væsentlig betydning for KOMBIT, at Leverandørens Ydelser generelt lever op til disse krav, og at Leverandøren leverer Ydel-

serne under Driftskontrakten, uanset om der måtte være fastsat Servicemål for Ydelserne, og der i øvrigt i dette bilag er specificeret særlige Ydelser, der skal leveres.

Leverandørens driftsansvar omfatter driftsafvikling under overholdelse af Servicemål for hele Systemet, herunder Programmel leveret af Leverandøren under Kontrakten såvel som Tred- jepartsprogrammel leveret af Tredjepartsprogrammelleverandør efter aftale med KOMBIT, jf. Driftskontraktens kapitel III. Visse Servicemål og krav er dog opdelt mellem de enkelte dele af Systemet og/eller Driftsmiljøet, således at der gælder selvstændige Servicemål og/eller

krav for separate dele af Driftsmiljøet. Denne opdeling af Servicemål og/eller krav gælder kun, hvor dette eksplicit er angivet i dette bilag 7.2.A.

Leverandøren skal opfylde alle Servicemål og krav, uanset om der måtte være en indbyrdes sammenhæng mellem de enkelte Servicemål og/eller krav. Det forhold, at Leverandøren

måtte have opfyldt et Servicemål og/eller et krav, indebærer således ikke, at Leverandøren fritages fra at opfylde et andet Servicemål og/eller krav uanset indbyrdes sammenhænge mellem de to Servicemål og/eller krav.

Blandt Leverandørens generelle og afgørende forpligtelser er Leverandørens pligt til at agere proaktivt i relation til KOMBITs øvrige leverandører og Anvendere, herunder Tredjepartspro- grammelleverandører og Anvendersystemleverandører, samt Interessenter. Heraf følger

blandt andet, at Leverandøren i forhold til alle Ydelser har pligt til i god tid at sikre, at KOM- BITs andre leverandører, herunder navnlig Tredjepartsprogrammelleverandører, leverer de ydelser, oplysninger mv., som de overfor KOMBIT er forpligtet til, og som er nødvendige for

Leverandørens opfyldelse af Driftskontrakten. Der henvises i øvrigt til Driftskontraktens punkt 16.

2.3 Måleperioder

[Punkt 2.3 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]

For Leverandørens Ydelser og Servicemål gælder følgende måleperioder.

- Måleperiode 1: Alle dage hele døgnet (24x7) Måleperioden er opdelt i 3 faser:

Fase 1 er i Beregningsperiode (Beregnings periode) Fase 2 er i Indlæsningsperiode (Aktiv periode)

Fase 3 er i Udlæsningsperiode (Passive Periode)

Opdeling i Faser har betydning for inplementering af Integrationer og Batch-kørsler i Incident Kategorier.

Medmindre andet er angivet i dette bilag, i Driftskontrakten eller øvrige bilag hertil, gælder der samme krav og Servicemål indenfor måleperioden.

2.4 Kritiske Servicemål og Kritiske ikke-månedlige Servicemål

Der er blandt de i dette bilag 7.2.A fastsatte Servicemål og Ydelser en række kritiske Ser- vicemål (herefter ”Kritiske Servicemål”) samt en række kritiske ikke-månedlige Servicemål (herefter ”Kritiske ikke-månedlige Servicemål”). Kategoriseringen af de enkelte Servicemål

har navnlig betydning i forhold til KOMBITs sanktioner ved Leverandørens manglende opfyl- delse af Driftskontrakten.

De Kritiske Servicemål og Kritiske ikke-månedlige Servicemål er angivet i henholdsvis punkt

2.4.1 og punkt 2.4.2.

2.4.1 Kritiske Servicemål

Følgende Servicemål udgør Kritiske Servicemål og er af væsentlig betydning for KOMBIT, jf. også Driftskontraktens punkt 28:

• Hvert enkelt Servicemål for reaktionstider, løsningstider og eskaleringstider for priori- tet A og B Incidents angivet under punkt 1

• Hvert enkelt Servicemål for orientering af KOMBIT og Interessenter om prioritet A og B Incidents angivet under punkt 1

• Hvert enkelt Servicemål for afhjælpning af prioritet A og B Problems angivet under punkt 9.4.1

• Hvert enkelt Servicemål for Root Cause Analyser for prioritet A og B Problems angivet under punkt 9.6

2.4.2 Kritiske ikke-månedlige Servicemål

Følgende Ydelser udgør Kritiske ikke-månedlige Servicemål og er af væsentlig betydning for KOMBIT, jf. også Driftskontraktens punkt 28:

• Restore test, som skal gennemføres en gang i kvartalet, jf. punkt 8.

• Disaster Recovery test rapport, som skal leveres senest 10 Arbejdsdage efter gen- nemført test, jf. punkt 25.3.

• Handlingsplanerne fra Disaster Recovery test rapport, som skal gennemføres indenfor 90 dage efter testens afslutning, jf. punkt 25.3.

• Levering af sikkerhedsrevisionserklæring, som bl.a. skal ske senest hvert år, jf. punkt 26.2.

2.5 Tvister om Servicemål

Hvis der er uenighed om, hvorvidt kravene til et Servicemål er opfyldt i en bestemt periode, kan hver af Parterne eskalere i henhold til Driftskontraktens punkt 33.2.

KAPITEL II Service Operation

3 Introduktion til Service Operation

Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leveran- døren skal levere som Service Operation under Driftskontrakten vedrørende driftsafvikling af Systemet.

Leverandørens rapportering vedrørende driftssituationen, herunder Dokumentation for over- holdelse af krav og Servicemål, er yderligere reguleret i bilag 7.2.G.

4 Incident Management

Leverandøren skal håndtere Incidents i henhold til Incident Management, som beskrevet un- der nærværende punkt og i øvrigt på en måde, som lever op til best practice på området.

Leverandøren skal med Incident Management processen sikre, at Systemet og driften heraf hurtigst muligt returneres til en tilstand, hvor Systemet kan anvendes i overensstemmelse

med Kontrakten, og således at en Incidents indvirkning på Anvendernes virksomhed og akti- viteter begrænses mest muligt.

Incident Management processen skal gennemføres i overensstemmelse med følgende pro- ces:

1) En Incident konstateres, indrapporteres og prioriteres, jf. punkt 4.2 – 4.7.

2) Leverandøren iværksætter alle aktiviteter, der er nødvendige for at få en Incident løst, jf. punkt 4.6, og alle øvrige aftalte aktiviteter inden for de aftalte Servicemål herfor, jf. punkt 4.7.

3) Leverandøren orienterer (løbende) KOMBIT og øvrige Interessenter om Incidenten og dens håndtering, jf. punkt 4.9.

4) Leverandøren orienterer KOMBIT og øvrige Interessenter om, at Incidenten er løst, herunder med rapportering til KOMBIT, jf. punkt 4.10.

5) Incident Management processen afsluttes i forhold til de(n) konkrete Incident(s), med- mindre KOMBIT kommer med indsigelser i forhold til Leverandørens rapport, jf. punkt 4.10.

Leverandøren skal i forbindelse med Ydelserne under Incident Management anvende IT Ser- vice Management systemet, der er beskrevet under punkt 10.2, herunder til registrering af

Incidents.

4.1 Generelle krav til Leverandørens Incident Management

Leverandøren skal i forbindelse med Incident Management blandt andet udføre og levere føl- gende Ydelser:

• Foretage registrering af og opfølgning på indrapporterede Incidents, jf. punkt 10.2.

Ved flere henvendelser vedrørende samme Incident skal disse så vidt muligt registre- res med direkte indbyrdes relationer med henblik på at bidrage til en effektiv håndte- ring.

• Reagere på og foretage registrering af egne konstateringer af eller indikationer på In- cidents, herunder i forbindelse med Events, jf. punkt 5.1.

• Foretage klassificering af Incidents for efterfølgende at kunne identificere relevante

indsatsområder med henblik på bl.a. at reducere antallet af Incidents. Klassificeringen kan eksempelvis basere sig på typer som gentagne Incidents, hardware Incidents, In- cidents på Integrationer mv.

• Prioritere Incidents i henhold til punkt 4.3.

• Løse Incidents, så Systemet og driften heraf genetableres til normal og som i Kontrak- ten forudsat tilstand, jf. punkt 1.

• Eskalering af Incidents til Tredjepartsprogrammelleverandør ved Incident, hvor årsa- gen til Incidenten skyldes eller kan skyldes forhold i Tredjepartsprogrammel fra den pågældende Tredjepartsprogrammelleverandør.

• Eskalering af Incidents til Anvendersystemleverandør ved Incident, hvor årsagen til

Incidenten skyldes eller kan skyldes forhold hos den pågældende Anvendersystemle- verandør, herunder fejl i data.

• Løbende opfølgning på Incidents, herunder navnlig Incidents, der er eskaleret til Tred- jepartsprogrammelleverandører samt Anvendersystemleverandører for at sikre den

nødvendige fremdrift i afhjælpningen eller omgåelsen af forholdet/forholdene, der er årsag til Incident(s).

• Løbende orientering af KOMBIT om fremdrift i løsningen af Incidents eskaleret til Tredjepartsprogrammelleverandører eller Anvendersystemleverandør.

• Såfremt eskalering er foretaget til tredjepart, skal Leverandøren fortsat aktivt afsøge andre, også mindre sandsynlige, årsager til Incidenten samt muligheder for løsning af Incidenten.

• Rekvirering af Root Cause Analyse for alle prioritet A og B Incidents fra Anvendersy- stemleverandører eller Tredjepartsprogrammelleverandør og fremsendelse af analy-

sen til KOMBIT. Såfremt Anvendersystemleverandør eller Tredjepartsprogrammelleve- randør ikke efterkommer anmodning om Root Cause Analyse, eskaleres sagen af Le- verandøren til KOMBITs driftschef eller dennes repræsentant.

• Løbende informering af den person, der har henvendt sig med Incident, om Inciden- tens håndtering.

• Informering af KOMBIT samt Brugere og Anvendere om fremdriften i håndteringen af Incidents med prioritet A og B.

• For alle Incidents udføres og afsluttes Incident Management processen, så der sikres optimalt samspil og overgang mellem Incident Management og Problem Management.

4.2 Indrapportering af information om Incidents

Leverandøren skal ved egen konstatering af samt ved henvendelser om og/eller indrapporte- ring af Incidents til Service Desk oprette en Incident Record og registrere følgende informa- tion:

• Unik identifikation

• Tidspunkt for Incidentens opståen samt konstatering

• Årsag til Incident

• Identifikation af den person og organisation, der har henvendt sig, eller alternativt, specifikation af, hvordan Leverandøren konstaterede Incidenten

• Kontaktperson i organisationen, der indrapporterede den pågældende Incident

• Beskrivelse af Incidenten, hvilket omfatter beskrivelse af den observerede Incident,

den observerede konsekvens, den Event, og/eller om muligt den Root Cause, der for- årsager Incidenten, samt udført handling og opnået reaktion herpå

• Forslag til Incident kategorisering

• Forslag til Incidentprioritering, jf. punkt 4.3 - Prioritering af Incidents

• Eventuelle bilag til belysning af Incidenten, eksempelvis skærmprints

• Relationer til andre Incidents og Problems

Ovenstående gælder, uanset om indrapportering sker telefonisk, via mail eller webformular, jf. punkt 10, eller Incidents konstateres af Leverandøren, herunder som led i driftsmonitore- ringen.

[Resten af punkt 4.2 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]

Starttiden for en Incident (”Incidentstarttiden”) er, når Leverandøren som led i sin Incident

Management proces, f.eks. ved en Event, eller i forbindelse med modtagelse af henvendelse til Service Desk eller til kontaktpersonen, jf. punkt 1, konstaterer eller burde have konstateret en Incident.

Incidentstarttiden kan aldrig være senere end henvendelsestidspunktet.

4.3 Prioritering af Incidents

[Punkt 4.3 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Alle Incidents prioriteres i prioritet A, B, C eller D i henhold til følgende definitioner:

Incidentprioritet

Beskrivelse

Eksempler i Produktionsmiljøet

Prioritet A

Kritisk Incident

Incidenten har eller vil have kritisk indvirkning på Systemet og/eller

løsningen af de opga- ver, som Systemet an- vendes til eller for.

En Incident har fx kritisk indvirkning, hvis en eller flere af følgende betingelser opfyldes:

• Incidenten udgør en kritisk sikkerhedsmæs- sig brist/risiko, herunder således, at der kan opnås uberettiget adgang til og/eller tab af personoplysninger, fortrolige oplysninger,

økonomiske oplysninger eller lignende kriti- ske oplysninger.

• Incidenten indebærer en kritisk forringelse af Systemets anvendelse, f.eks. i form af

følgende:

o Systemet er utilgængeligt for alle Bru- gere hos én eller flere Anvendere eller Anvendernes Systemer;

o Systemet og/eller afgørende funktionali- tet er utilgængeligt for mere end 20 % af samtlige Brugere;

o Incidenten indebærer ukorrekte bereg- ninger i Anvendersystemer;

o Incidenten indebærer, at kritisk funktio- nalitet er utilgængelig;

o Der sker nedbrud på netværksforbindel- ser, herunder til tredjeparter;

• En Kritisk Integration, jf. punkt 4.4, fejler;

• Tre Vigtige Integrationer, jf. punkt 4.4 fejler;

• En Kritisk Batchkørsel, jf. punkt 4.5 fejler;

Incidentprioritet	Beskrivelse	Eksempler i Produktionsmiljøet
		• Overskridelse af Servicemål for Xxxxxxxxx Xxxxxxxxx, jf. punkt 14.3 med underpunkter.
Prioritet B Alvorlig Incident	Incidenten har eller vil have alvorlig indvirkning på Systemet og/eller løsningen af de opga- ver, som Systemet an- vendes til eller for.	En Incident har fx alvorlig indvirkning, hvis en eller flere af følgende betingelser opfyldes: • Incidenten har alvorlig indvirkning på an- vendelsen af Systemet, herunder på funkti- onalitet, indeks, tabeller eller data, som Sy- stemet udstiller fra Anvendersystem, som Systemet er tilsluttet, eller Systemets in- terne funktionalitet i øvrigt; • Systemet kan ikke anvendes af Brugerne hvor: o mere end 50 % af Brugerne hos en An- vender kan ikke anvende Systemet; eller o mere end 5 % af samtlige Brugere kan ikke anvende Systemet fuldt; • En Vigtig Integration, jf. punkt 4.4, fejler • 3 Mindre Vigtige Integrationer, jf. punkt 4.4, fejler; • En Mindre Vigtig Integration, jf. punkt 4.4, fejler gentagende gange; • En Vigtig Batchkørsel, jf. punkt 4.5, fejler; • En Mindre Vigtig Batchkørsel, jf. punkt 4.5, fejler gentagende gange; • En prioritet C eller D Incident, der kan forår- sage en prioritet A eller B Incident; • Hvis dataelementer er beskadiget, tabt eller utilgængelige; • Input eller output data, elementer eller be- skeder, der er klar til at blive processeret, har ventet på sådan processering i mere end 2 timer, medmindre andet fremgår af Leverancebeskrivelsen; • Ind- og Udlæsningshastigheden bliver ikke overholdt jfr. 7.2; • Overskridelse af Servicemål for Ønskede Svartider, jf. punkt 14.3 med underpunkter;
Prioritet C Betydende Inci- dent	Incidenten har eller vil have betydende indvirk- ning på Systemet og/el- ler løsningen af de op- gaver, som Systemet anvendes til eller for.	En Incident har fx betydende indvirkning, hvis en eller flere af følgende betingelser opfyldes: • En Incident, som Brugere eller Anvendere kan undgå ved alternativ arbejdsgang, eller som ikke er væsentlig for anvendelsen af Systemet; • En Mindre Vigtig Integration, jf. punkt 4.4, fejler; • En Mindre Vigtig Batchkørsel, jf. punkt 4.5, fejler
Prioritet D	Incidenten har eller vil have mindre betydende	En Incident har fx mindre betydende indvirk- ning, hvis følgende betingelse opfyldes:

Incidentprioritet

Beskrivelse

Eksempler i Produktionsmiljøet

Mindre bety-

dende Incident

indvirkning på Systemet og/eller løsningen af de

opgaver, som Systemet anvendes til eller for.

• En mindre betydende Incident, som medfø- rer gene for Brugere eller Anvendere, men ikke blokerer for anvendelse;

Tabel 2: Prioritering af Incidents

Det er Leverandørens ansvar at tildele Incidents prioritet i overensstemmelse med ovenstå- ende definitioner samt at vurdere årsag til Incident, og om Incidenten skal løses af og der- med ved eskalering til tredjemand.

Ved uenighed om en Incidents prioritering, eller hvorvidt Incidenten skal løses af og ved

eskalering til tredjemand, træffer KOMBIT beslutning herom, idet Leverandøren dog i så fald kan eskalere spørgsmålet i overensstemmelse med Driftskontraktens punkt 33.2. Som alter- nativ til en eskalation kan Parterne aftale, at afgørelsen på Parternes uenighed udskydes,

herunder med mulighed for efterfølgende eskalation.

Indtil spørgsmålet om prioritering af og/eller ansvaret for løsningen af Incidenten er afgjort, skal Leverandøren håndtere denne i henhold til KOMBITs beslutning. Viser det sig efterføl- gende gennem fælles erkendelse eller den sagkyndiges afgørelse, at Incidenten burde have

været prioriteret og/eller løst af andre som anført af Leverandøren, kan Leverandøren kræve dokumenterede meromkostninger, herunder i forbindelse med nødvendiggjort merarbejde

som følge af KOMBITs fejlagtige prioritering og/eller ansvarsplacering, dækket af KOMBIT, idet det dokumenterede merarbejde betales i overensstemmelse med Driftskontraktens be- stemmelser om udførelse af timebaserede ressourcer.

Servicemålene for de enkelte Incidents prioritet gælder i alle tilfælde, uanset hvornår og

hvordan Leverandøren har prioriteret en Incident. Dette princip illustreres ved følgende ek- sempler:

Leverandøren burde have konstateret en prioritet B Incident mandag kl. 9.00.

- Servicemålene for prioritet B Incidents gælder fra mandag kl. 9.00, uanset om Leve- randøren først konstaterer og/eller prioriterer Incidenten mandag kl. 10.00.

- Servicemålene for prioritet B Incidents gælder ligeledes fra mandag kl. 9.00, uanset om Leverandøren – med eller uden indsigelser fra KOMBIT – prioriterer Incidenten ukorrekt, eksempelvis som en prioritet C Incident.

4.4 Kategorisering af Integrationer til incidentprioritering

[Punkt 4.4 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Såfremt der opstår Fejl og andre driftsforstyrrelser i forhold til en Integration, håndteres dette som en Incident i overensstemmelse med de Servicemål, som er gældende for håndtering af Incidents.

Til brug for prioriteringen af Incidents for Integrationer, jf. punkt 4.3, kategoriseres alle Inte- grationer i følgende kategorier:

Integrationskatego- rier

Eksempler på Integrationer i Pro- duktionsmiljøet

Incidentprioritering

Kritisk Integration

Integrationen har kri- tisk betydning for Sy-

stemet og/eller løsnin- gen af de opgaver,

som Systemet anven- des til eller for.

• En Integration til et andet sy- stem som er afhængig af Inte-

grationen i forbindelse med ud- betalinger eller afgørelser i

myndighedssager.

• En Integration til et andet sy-

stem som anvendes af mindst 5 Anvendere

• Integrationen indlæser kritisk

data i Systemet, som skal være konsistent og retvisende fx data om systemers og brugeres ret- tigheder.

• Indlæsning af Data til Systemet i den Primære Data Indlæs-

ningsperioden

Fejl og andre driftsforstyr- relser ved sådanne Inte-

grationer skal som Incident prioriteres som prioritet A

Vigtig Integration

Integrationen har vigtig betydning for Systemet og/eller løsningen af

de opgaver, som Sy-

stemet anvendes til el- ler for.

• En Integration til et andet sy-

stem som anvendes af mindst 2 Anvendere

• Integrationen indlæser vigtig

data i Systemet, som skal være konsistent og retvisende. Fx

persondata som er følsomt eller semifølsomt

Fejl og andre driftsforstyr- relser ved sådanne Inte-

grationer skal som Incident prioriteres som prioritet B

Mindre Vigtig Integra- tion

Integrationen har min- dre vigtig betydning for Systemet og/eller løs- ningen af de opgaver,

som Systemet anven- des til eller for.

• En Integration til et andet sy- stem, hvor Anvendere ikke er væsentligt påvirket.

• Integrationen indlæser mindre

vigtig data i Systemet, som skal være konsistent og retvisende.

• Indlæsning af Data til Systemet i Passiv Perioden

Fejl og andre driftsforstyr- relser ved sådanne Inte-

grationer skal som Incident prioriteres som prioritet C

Tabel 3 Integrationskategorier

De enkelte Integrationer kategoriseres af KOMBIT inden Overtagelsesprøvens påbegyn-

delse, og på baggrund af deres vigtighed i forhold til driftsafviklingen af Systemet og effekt for Brugere og Anvendere. Er en Integration ikke kategoriseret, skal den kategoriseres som

en Kritisk Integration. Integrationer skal dokumenteres af Leverandøren i Driftshåndbogen, jf. bilag 7.2.F.

Der er efter forudgående skriftlig aftale med KOMBIT mulighed for at nedgradere prioriteten af en Incident med ét niveau, hvis en konkret Fejl eller driftsforstyrrelse vurderes som mindre betydende, jf. følgende eksempel. KOMBIT kan afvise et ønske fra Leverandøren om at ned- gradere prioriteten af en Incident.

Eksempel:

Der konstateres en Fejl ved afvikling af en Kritisk Integration. Der skal som følge heraf oprettes en Prioritet A Incident på Fejlen. Indledende fejlsøgning afdækker, at Fejlen

hverken blokerer for anvendelse af Systemet eller medfører, at Brugerne skal anvende alternative arbejdsgange. KOMBIT orienteres herom, og hvis KOMBIT skriftligt erklærer sig enig i vurderingen, nedgraderes Incidentet fra prioritet A til prioritet B.

Tilsvarende kan en Fejl i en Vigtig Integration nedgraderes fra prioritet B til prioritet C In- cident og en Fejl i en Mindre Vigtig Integration nedgraderes fra prioritet C til D Incident, hvis KOMBIT forinden skriftligt har erklæret sig enig i Leverandørens vurdering.

4.5 Kategorisering af Batchkørsler til Incidentprioritering

[Punkt 4.5 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Såfremt der sker Fejl og andre driftsforstyrrelser i forhold til en Batchkørsel (herunder forsin- kelse eller kun delvis afvikling), håndteres dette som en Incident og følger de Servicemål,

som er gældende for håndtering af Incidents.

Til brug for prioriteringen af Incidents for Batchkørsler, jf. ovenstående punkt 1, kategoriseres alle Batchkørsler i følgende kategorier:

Batchkørsel kategorier	Eksempler på Batchkørsler i Pro- duktionsmiljøet	Beskrivelse
Kritisk Batch- kørsel	• En Batchkørsel, hvor et andet system er afhængig af Batch- kørslen i forbindelse med udbe- talinger eller afgørelser i myn- dighedssager. • En Batchkørsel, som påvirker et andet system, som anvendes af mindst 5 Anvendere • Batchkørslen indeholder kritisk data fra Anvendersystemer fx vedrørende sikkerhed eller mas- seopdateringer fra registre.	Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som In- cident prioriteres som prioritet A
Betydende Batchkørsel	• En Batchkørsel som påvirker et andet system som anvendes af mindst 2 Anvendere • Batchkørslen indeholder vigtig data fra Anvendersystemer fx indlæsning eller udtræk af data, som indeholder persondata, som er følsomme eller semiføl- somme.	Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som In- cident prioriteres som prioritet B
Underordnede Batchkørsel	• En Batchkørsel, som påvirker et andet system, hvis Anvendere ikke er væsentligt påvirket. • Batchkørslen indeholder mindre vigtig data.	Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som In- cident prioriteres som prioritet C

Tabel 4: Batchkørsel kategorier

De enkelte Batchkørsler kategoriseres af KOMBIT inden Overtagelsensprøvens påbegyn- delse, og på baggrund af deres vigtighed i forhold til driftsafviklingen af Systemet og effekt

for Brugere og Anvendere. Er en Batchkørsel ikke kategoriseret, skal den kategoriseres som en Betydende Batchkørsel. Batchkørsler skal dokumenteres i Driftshåndbogen, jf. bilag 7.2.F.

Der er efter forudgående skriftlig aftale med KOMBIT mulighed for at nedgradere prioriteten af en Incident med ét niveau, hvis en konkret Batchkørsel vurderes som mindre vigtig end

beskrevet, jf. følgende eksempel. KOMBIT kan afvise et ønske fra Leverandøren om at ned- gradere prioriteten af en Incident.

Eksempel:

Der konstateres en Fejl ved afvikling af en Kritisk Batchkørsel. Der oprettes en prioritet A Incident på Fejlen. Indledende fejlsøgning afdækker, at Incidenten ikke har eller kan

have kritisk indvirkning på Systemet. KOMBIT orienteres herom, og hvis KOMBIT skrift- ligt erklærer sig enig i vurderingen, nedgraderes Incidentet fra prioritet A til prioritet B.

Tilsvarende kan en Fejl i en Betydende Batchkørsel nedgraderes fra prioritet B til prioritet C Incident, og en Fejl i en Underordnede Batchkørsel nedgraderes fra prioritet C til D In- cident, hvis KOMBIT forinden er hørt herom og skriftligt har erklæret sig enig i Leveran-

dørens vurdering.

4.6 Løsning af Incidents

[Punkt 4.6 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Leverandøren skal under Incident Management løse Incidents i overensstemmelse med Ser- vicemål herfor.

Incidents kan løses ved Omgåelse, jf. punkt 1, eller afhjælpning, jf. punkt 1. Uanset, om Inci- dents løses ved Omgåelse eller afhjælpning, skal Leverandøren udføre alle aktiviteter, der er nødvendige for at løse Incidents i henhold til de Servicemål, der fremgår af punkt 1, herunder ved levering af nødvendigt supplerende Infrastruktur, Programmel, programmel i Driftsmiljøet og konsulentbistand. Arbejdet med løsningen af Incidents skal derudover overholde Drifts-

kontraktens garantier og øvrige bestemmelser, jf. herunder Driftskontraktens punkt 5 og 6.

Incidents anses først for løst, når Systemet og driften heraf er returneret til normal drift og en tilstand, hvor Systemet kan anvendes i henhold til Kontrakten, og de(n) pågældende Inci-

dents indvirkning(er) på Anvendernes anvendelse og anvendelsesmuligheder af Systemet er minimal. Såfremt fuldstændig Omgåelse/afhjælpning af en Incident ikke umiddelbart er mulig, har Leverandøren uden ugrundet ophold pligt til at implementere delvis Omgåelse/afhjælp-

ning, således at Incidentens ulempe for KOMBIT til enhver tid er mindst mulig. Delvis Omgå- else/afhjælpning skal godkendes af KOMBIT. Godkendelse af en delvis Omgåelse/afhjælp- ning af en Incident anses ikke som løsning af en Incident, dog kan KOMBIT vælge at ned-

sætte prioriteten for Incidenten, jf. punkt 1.

4.6.1 Omgåelse

[Punkt 4.6.1 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Ved Omgåelse fjernes Incidentens effekt på og/eller risiko for effekt på Systemets anvende- lighed således, at Systemet lever op til Kontraktens krav og bestemmelser, og/eller at risi-

koen for driftsforstyrrelser i Systemets anvendelighed er fjernet. Ved Omgåelse sker der ikke eliminering af Incidentens Root Cause. For at en fuldstændig Omgåelse af en Incident kan

accepteres som løsning af en Incident, kræves KOMBITs godkendelse af den fuldstændige Omgåelse.

Omgåelse kan eksempelvis gennemføres ved følgende aktiviteter:

• Rettelse til Driftsmiljøet

• Rettelse i Konfigurationsmateriale eller Programmel

4.6.2 Afhjælpning

[Punkt 4.6.2 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Ved afhjælpning fjernes dels Incidentens effekt på og/eller risiko for effekt på Systemets an- vendelighed som ved Omgåelse, dels Incidentens Root Cause.

Efter afhjælpning skal såvel Systemet, driften som Leverandørens øvrige Ydelser således opfylde Kontraktens krav, idet Fejl blandt andet skal være afhjulpet.

Afhjælpning kan eksempelvis gennemføres ved følgende aktiviteter:

• Rettelse til Driftsmiljøet

• Rettelse i Konfigurationsmateriale eller Programmel

4.6.3 Leverandørens generelle ansvar

Leverandøren har uanset, hvor en Incident forekommer eller årsagen hertil, det overordnede ansvar for, at Incidents bliver løst, således at Systemet fungerer og kan anvendes i overens- stemmelse med Kontrakten, herunder i overensstemmelse med Servicemålene angivet i in- deværende bilag.

Leverandøren har således også det overordnede koordinerings- og opfølgningsansvar over for Anvendersystemleverandører og Tredjepartsprogrammelleverandører i forhold til Inci-

dents, som skyldes fejl eller andre forhold i henholdsvis Anvendersystemer og Tredjeparts- programmel. Leverandøren kan dog ikke stilles til ansvar for funktionaliteten og/eller tilgæn- geligheden af Anvendersystemer henholdsvis Tredjepartsprogrammel.

Uanset om Incidents er forårsaget af fejl/forhold i Anvendersystemer eller i Tredjepartspro- grammel, gælder således følgende:

• Leverandøren skal straks rapportere fejlen/det pågældende forhold til den pågæl-

dende tredjemand og indhente dennes bekræftelse på, at forholdet er accepteret som en rapportering af fejl eller lignende.

• For så vidt angår Anvendersystemleverandører og Tredjepartsprogrammelleverandø-

rer skal Leverandøren proaktivt sikre, at disse bekræfter over for Leverandøren, at for- holdet håndteres i overensstemmelse med KOMBITs aftale med den pågældende

tredjemand, og at de oplyser, hvorledes dette sker eller følge proceduren for eskala- tion.

• Når Tredjepartsprogrammelleverandører har leveret en rettelse af en fejl eller anvist relevant Omgåelse, skal Leverandøren straks sørge for orientering af KOMBIT samt installation via Change Management processen i Driftsmiljøet efter behørig test, jf. punkt 17.

Når fejlen/forholdet, der forårsagede Incidenten, er afhjulpet, skal Leverandøren uden ugrun- det ophold sikre, at Kontraktens krav er opfyldt, herunder at Systemet anvender Integrationer korrekt.

4.7 Servicemål for Incident Management

[Punktet 4.7 med underpunkter udgør minimumskrav, som Tilbudsgiver ikke kan tage forbe- hold overfor].

Servicemål for Incident Management baserer sig på reaktionstider, løsningstider, og eskale- ringstider.

Reaktionstider gælder for alle Incidents.

Løsningstiden gælder for alle Incidents, idet Servicemålet dog er modificeret i forhold til Inci- dents, der skyldes fejl eller andre forhold i Anvendersystemer eller i Tredjepartsprogrammel. Servicemålet gælder således fuldt ud for Incidents, der skyldes Fejl i ethvert Programmel.

Eskaleringstider gælder alene for Incidents, der skyldes forhold i et Anvendersystem eller i Tredjepartsprogrammel.

Dog gælder det for Præproduktionsmiljø og Eksternt Testmiljø, at servicemålene for reakti-

onstider, løsningstider og eskaleringstider højst kan følge angivelserne som en prioritet C In- cident, selvom Incidenten har prioritet A eller B.

Såfremt Leverandøren ikke har opfyldt kravene til Monitorering og Event Management, jf. punkt 5, og en Incident kunne have været konstateret tidligere ved en opfyldelse af disse krav, skal de enkelte tider regnes fra det tidspunkt, hvor en tilstrækkelig driftsmonitorering ville have udløst et Event for den pågældende Incident.

Servicemålene for de enkelte tider fremgår under punkt 4.7.1 til 4.7.3 .

4.7.1 Reaktionstiden

Reaktionstiden er fra Incidentstarttiden, jf. punkt 1, til Leverandøren har gennemført registre- ring af en Incident Record, herunder forslag til klassificering og forslag til prioritering af den pågældende Incident, samt har påbegyndt diagnosticeringen, samt reageret overfor involve- rede parter. Servicemål for reaktionstiden gælder, uanset om Incidents, herunder Fejl, skyl-

des Leverandørens forhold eller andre forhold, herunder Tredjepartsprogrammelleverandører eller Anvendersystemleverandører.

4.7.2 Løsningstiden

Løsningstiden er fra Incidentstarttiden, til Leverandøren har løst Incidenten i overensstem- melse med punkt 4.10 og dette punkt.

For så vidt angår Incidents, der skyldes fejl eller andre forhold i Anvendersystemer eller i Tredjepartsprogrammel, gælder følgende:

Leverandøren skal inden for løsningstiden i videst mulige omfang løse Incidenten. Såfremt dette ikke er muligt, skal Leverandøren søge at begrænse Incidentens påvirkning af Syste-

mets anvendelse. Dette kan eksempelvis omfatte, at Leverandøren tydeligt informerer KOM- BIT om alternativ arbejdsgang for Systemets anvendelse (Omgåelse). Såfremt dette ikke er muligt, skal Leverandøren skriftligt inden for løsningstiden dokumentere, hvorfor det ikke er muligt for Leverandøren at løse Incidenten, herunder udarbejde et udkast til en skriftlig orien- tering af berørte Interessenter, jf. punkt 4.8, som skal forelægges KOMBIT til godkendelse.

Leverandøren skal efter KOMBITs godkendelse udsende den skriftlige orientering til Interes- senterne i en form, som er aftalt med KOMBIT.

4.7.3 Eskaleringstiden

Eskaleringstiden regnes fra Incidentstarttiden, til Leverandøren har orienteret Anvendersy- stemleverandøren og/eller Tredjepartsprogrammelleverandøren om forholdet. Eskaleringsti- der måles alene inden for Tredjepartsprogrammelleverandørens eller Anvendersystemleve- randørens åbningstid.

Leverandøren skal aktivt og med intervaller svarende til Servicemålene for eskaleringstiderne følge op på afhjælpningen og rapportere status til KOMBIT.

I tilfælde af eksempelvis en prioritet A Incident skal Leverandøren således i Måleperioden følge op på afhjælpningen hver 60. minut samt rapportere status til KOMBIT, jf. punkt 4.9.

I forhold til prioritet B Incidents skal Leverandøren følge op på afhjælpningen hver 120. minut samt rapportere status til KOMBIT.

Ved prioritet C Incidents skal Leverandøren følge op på rapporteringen én gang dagligt alle Arbejdsdage.

Ved prioritet D Incidents skal Leverandøren følge op på rapporteringen hver tredje Arbejds- dag.

Der er i konkrete tilfælde af Incidents mulighed for efter forudgående skriftlig aftale med

KOMBIT at ændre opfølgnings- og rapporteringsfrekvensen, hvis dette er sagligt begrundet. KOMBIT kan dog frit afvise en anmodning herom fra Leverandøren.

Leverandøren skal kunne dokumentere, at der er foretaget opfølgning i overensstemmelse med ovenstående, såfremt KOMBIT anmoder herom.

Eskalerer Leverandøren en Incident til en Anvendersystemleverandør eller en Tredjeparts-

programmelleverandør, og viser det sig efterfølgende, at Leverandøren selv var ansvarlig for Incidenten, beregnes løsningstiden i overensstemmelse med de definerede Servicemål her- for, jf. ovenstående definitioner. Tiden, der er anvendt i forbindelse med fejlagtig eskalering

til én eller flere Anvendersystemleverandør(er) eller Tredjepartsprogrammelleverandør(er), eller anden tid fragår således ikke i opgørelsen af de pågældende Servicemål.

I perioder med Hypercare, skal Eskalationstiderne for Hypercare følges.

4.7.4 Servicemål

Servicemål angivet i nedenstående og skal opfyldes med 90 % fraktilen for alle målte tider i løbet af en kalendermåned.

Servicemål for Incident Management i”Målepe- riode 1”	Reaktionstid	Eskaleringstid	Løsningstid
Prioritet A Incidents	30 minutter	60 minutter	180 minutter
Prioritet B Incidents	60 minutter	120 minutter	360 minutter
Prioritet C Incidents	300 minutter	1 Arbejdsdag	3 Arbejdsdage
Prioritet D Incidents	3 Arbejdsdage	3 Arbejdsdage	10 Arbejdsdage, medmindre Parterne aftaler andet

Tabel 5: Servicemål for Incident Management i Måleperiode 1

I perioder med Hypercare, skal Reaktionstiderne for Hypercare følges. Se Bilag 7.2.B.

4.8 Kontaktperson til KOMBITs rapportering af Incidents

Leverandøren skal sikre, at driftschef hos KOMBIT eller dennes repræsentant ud over mulig- heden for at henvende sig til Service Desk, jf. punkt 10, har mulighed for at rapportere Inci- dents via telefon og mail til følgende kontaktperson:

Navn, stilling for Incident Manager

Tlf.

Mobil Mail

[Incident - Udfyldes af Tilbudsgiver]

[Udfyldes af Tilbudsgiver]

Evt Hypercare kontaktperson

[Udfyldes af Tilbudsgiver]

Tabel 6: Kontaktperson til KOMBIT

4.9 Eskalering til KOMBIT samt orientering om Incidents til Bru- gere mf.

For alle Incidents, der er prioriteret som prioritet A og B, og uanset om Incidenten er forårsa- get af Fejl i Programmel, fejl eller lignende i Tredjepartsprogrammel eller Anvendersystemer, eller andre forhold, skal disse håndteres af en Major Incident Manager hos Leverandøren.

Major Incident Manageren er ansvarlig for al koordinering og kommunikation i egen organisa- tion samt med alle Interessenter.

Leverandøren skal eskalere alle kritiske forhold, herunder i forhold til samarbejdet med Tred- jepartsprogrammelleverandører og Anvendersystemleverandører, til KOMBITs driftschef, li- gesom Leverandøren løbende skal holde Interessenterne orienteret om kritiske forhold i for- hold til Incidents.

Leverandørens Ydelser omfatter navnlig følgende:

• Eskalering til KOMBITs driftschef eller dennes repræsentant, primært via telefon, se- kundært via SMS og mail til mailadresse xxxxx@xxxxxx.xx .

• Efter eskalering skal Leverandøren løbende orientere KOMBIT minimum hver time i Måleperiode 1, medmindre andet er aftalt.

• Orientering af alle Brugere og Interessenter uden unødigt ophold om alle relevante

driftsforhold vedrørende prioritet A og B Incidents. Dette omfatter eksempelvis Events, som skyldes eksterne forhold, eksempelvis nedbrud hos Anvendersystemleverandø-

rer.

• Løbende publicering af information for Brugere og Interessenter. Dette omfatter kom- munikation ved hjælp af mail, en dertil indrettet hjemmeside samt gennem automatisk velkomsthilsen på telefonindgangen før gennemstilling til Service Desk. Desuden ud- stilles informationer om driftsstatus via Systemet.

• Pligt til med et varsel på 30 minutter i både Måleperiode 1 at deltage i løbende tele- fonmøder omkring status på Incidenten, såfremt KOMBIT stiller krav herom.

• Leverandøren skal, såfremt KOMBITs driftschef eller dennes repræsentant stiller krav herom, tillade, at KOMBITs driftschef eller dennes repræsentant deltager i møder med relevante parter, herunder Xxxxxxxxxxxxxxxxxxxxxxx eller Underleverandører omhand- lende Omgåelse og afhjælpning af prioritet A og B Incidents.

4.9.1 Servicemål for orientering af KOMBIT og Interessenter

KOMBITs driftschef eller dennes repræsentant skal orienteres om Incidents i overensstem- melse med Servicemålene under dette punkt.

Hvert Servicemål, som angivet i det følgende, skal opfyldes individuelt for alle målte tider i løbet af en kalendermåned.

Servicemål indenfor Måleperiode 1:

• Prioritet A og B Incidents skal meddeles KOMBITs driftschef eller dennes repræsen- tant inden for en ½ time fra Incidents er oprettet, primært på telefon, sekundært via SMS og mail

• Inden for en ½ time fra prioritet A eller prioritet B Incidents er oprettet, skal informatio- nen herom være tilgængelig for Brugere og Interessenter på velkomsthilsen på tele-

fonindgangen, en af Leverandøren dertil indrettet hjemmeside og/eller mail til berørte Brugere og Anvendere med driftsstatus

• Leverandøren skal mindst hver 2 time opdatere både driftschef eller denne repræsen- tant per telefon eller efter aftale samt opdatere den dertil indrettet hjemmeside og/eller mail.

Tiden for orientering af KOMBITs driftschef eller dennes repræsentant måles fra Incident- starttiden, jf. punkt 4, til Leverandøren har meddelt Incidenten til KOMBITs driftschef eller dennes repræsentant. Leverandøren skal i IT Service Management it- systemet logge tids- punkter for forsøg på at opnå telefonisk kontakt med samt afsendelse af SMS og mail til

KOMBITs driftschef og/eller dennes repræsentant.

Tiden for information til Brugere og Interessenter måles fra Incidentstarttiden, til Leverandø- ren har informeret Xxxxxxx og Interessenter på den anførte måde.

I perioder med Hypercare skal Servicemålene for Hypercare overholdes.

Der er ikke forskel på Reaktions-, Løsnings-, og Eskaleringstiden uanset hvilket periode de optræder på.

4.10 Afslutning på Incident Management processen

En Incident anses først som afsluttet, når den er løst i overensstemmelse med kravene i

punkt 4.6, og KOMBITs driftschef har modtaget Leverandørens skriftlige orientering herom.

Leverandøren skal senest 2 Dage efter, at en Incident med prioritet A eller B er løst, frem- sende en incidentrapport til KOMBIT. I det tilfælde, at en Incident løses på en ikke-Arbejds- dag, og de to efterfølgende Dage heller ikke er Arbejdsdage, gælder dog, at incidentrappor- ten senest skal fremsendes kl. 12.00 den næstkommende Arbejdsdag.

Incidentrapporten skal indeholde følgende oplysninger:

• Om de(n) pågældende Incident(s) er løst ved Omgåelse eller afhjælpning.

• Dokumentering af, hvordan Incidents er løst, således at Leverandøren gør det muligt i Incident Management processen at løse tilsvarende Incidents, indtil Root Cause for

Incident er afhjulpet.

• Tidspunkt for Incidents opståen, tidspunkt for klarmelding efter reetablering af normal drift, Incidentens art, Root Cause herfor og den foretagne løsning samt en angivelse af det samlede tidsrum, der skal fratrækkes Tilgængelig Driftstid som følge af Inciden- ten, jf. punkt 13.

• Om de(n) pågældende Incident(s) er eskaleret til Problem Management, jf. punkt 9, og i givet fald hvornår dette er sket.

Leverandøren skal efterkomme rimelige og saglige krav fra KOMBIT i forhold til såvel yderli- gere opfølgning som håndtering af en Incident, herunder i forhold til eskalering til Problem Management, samt til ændringer til incidentrapporten.

Såfremt KOMBIT ikke fremkommer med indsigelser mod incidentrapporten senest 10 Dage

efter modtagelsen heraf, anses incidentrapporten og Leverandørens håndtering af Incidenten som godkendt og i overensstemmelse med Driftskontrakten.

Såfremt der er uenighed om ovenstående, kan hver af Parterne eskalere spørgsmålet i hen- hold til Driftskontraktens punkt 33.2.

En Incident Record lukkes først, når Incidenten er afhjulpet, jf. punkt 4.10. Dermed forbliver Incident Record åben, så længe en Incident ikke er løst eller er løst ved Omgåelse.

4.10.1 Årsags Analyser i forbindelse med Incident afslutning

Det er et Servicemål, at der fremsendes en Årsagsanalyse (Root Cause Analyse - RCA) for prioritet A og B Incident senest 5 Arbejdsdage efter det pågældende Incident er konstateret.

Dog gælder det, at såfremt årsagen til Incident ikke er Leverandørens ansvar, og færdiggø- relse af Root Cause Analyse forsinkes grundet afventning af Tredjepartsprogrammelleveran-

dører, Anvendersystemleverandører eller Anvendere, kan Leverandøren ikke gøres ansvarlig for forsinkelse ved levering af RCA. I stedet skal Leverandøren inden for Servicemålet anføre en plan for indhentning af RCA-oplysninger fra Tredjepartsprogrammelleverandører, Anven- dersystemleverandører eller Anvendere

5 Monitorering, Event og Log-Management

Leverandøren skal monitorere driftsafviklingen af Systemet i Produktionsmiljøet.

Leverandøren skal løbende udføre proaktiv Monitorering af server ressourcer og øvrig kapa- citet mv. i Produktionsmiljøet, herunder CPU, RAM, lagerplads, netværk, serverprocesser mv.

Leverandøren skal herunder levere følgende Ydelser i forbindelse med Monitorering og Event Management:

• Monitorering og logning af Systemet i Produktionsmiljøet samt selve Produktionsmil- jøet.

• Performancemålinger i forbindelse med Monitorering.

• Måling af belastning af Produktionsmiljøet i forbindelse med Monitorering med henblik på rettidig udvidelse af kapaciteten.

• Etablering og vedligeholdelse af Events i monitoreringsværktøjerne i Produktionsmil- jøet, specifikt for svartidsmålinger og belastningsmålinger af Systemet.

• Indrapportering og opfølgning af relevante Events som Incidents.

• Proaktivt behandle negative trends.

• Publicere Monitorering og Event Management data for KOMBIT fx i Leverandørens IT Service Management system eller på en dertil indrettet hjemmeside

• Gøre Monitorering og Event Management data tilgængelige for KOMBIT i maskinlæs- bart format

5.1 Events

Leverandøren skal som en del af Leverandørens Event Management proces specificere me- tode og grænseniveauer for Events til brug for Monitorering af driftsafviklingen af Systemet. På basis af metode og grænseniveauer skal Leverandøren opsætte og overvåge Driftsmiljøet ved anvendelse af monitoreringsværktøjer. Overvågningen skal som minimum etableres til

alle dele af Systemet og Produktionsmiljøet, således at alle driftsforstyrrelser og potentielle driftsforstyrrelser udløser Events.

Events skal sikre effektiv advisering af Leverandøren, når Systemets driftsafvikling påvirkes i en grad, der kan påvirke overholdelsen af Servicemål for Systemet. Events skal gøre det mu- ligt at forebygge risikoen for Incidents.

Leverandøren skal sikre, at det er muligt for KOMBIT, eller en repræsentant for KOMBIT, at få fjernadgang til monitoreringsinformationen for den aktuelle driftssituation samt historiske driftsdata, herunder overblikket over Events.

Leverandøren skal sikre, at alle relevante Events registreres som Incidents, og at disse adresseres i henhold til gældende Servicemål, jf. punkt 4.

5.2 Logning

Leverandøren skal sikre, at der gennemføres en logning i overensstemmelse med bilag 2.1 og som lever op til best practice på området.

Logningen kan udover de i Kontrakten, herunder bilag 2.1 samt Driftskontrakten, nævnte logs, blandt andet være driftslogs som database logs, backup logs, event logs og access logs.

Leverandøren skal til enhver tid sikre, at der forefindes verifikationslogdata, der understøtter opgørelse af svartider og tilgængelighed af Systemet samt tilgængelighed af Systemets Inte- grationer..

Logningen skal ske på en måde, som sikrer, at logs kan anvendes i arbejdet med at analy- sere Events og Incidents samt andre hændelser og aktiviteter i forbindelse med driften. Log-

ningen skal desuden foretages i et omfang, som understøtter revision og audit af Leverandø- ren og Ydelserne samt overholdelse af persondataloven.

For at KOMBIT kan etablere sin egen detaljerede overvågning af Systems driftsafvikling, skal Leverandøren sikre, at det er muligt for KOMBIT, eller en repræsentant for KOMBIT, at tilgå

live log data i maskinlæsbart format. Logdata skal kunne hentes via en Integration. Denne Integration kategoriseres som en Mindre Vigtig Integration.

6 Driftsafvikling af Batchkørsler

Det er Leverandørens ansvar at overvåge, håndtere og gennemføre Batchkørsler i tilknytning til Systemet i overensstemmelse med best practice og i øvrigt inden for det tidsrum, som Par- terne har aftalt, jf. bilag 7.2.F.

Parterne skal løbende i Driftskontraktens løbetid vurdere, om tidsrummet og prioritering for planlagte Batchkørsler er optimale. Hvis der vurderes at være behov for ændringer, ændres tidsrummet og prioritering i overensstemmelse hermed, hvorefter dette opdateres i Drifts-

håndbogen x.xx. Bilag 7.2.F. Såfremt der er uenighed mellem Parterne i forhold til fastsættel- sen af planlagte Batchkørsler, eskaleres og løses Parternes uenighed i overensstemmelse med Driftskontraktens punkt 33.2.

Selvom det ikke lykkes at gennemføre en planlagt Batchkørsel succesfuldt, skal Systemet

fortsætte i en stabil tilstand. Den fejlede Batchkørsel skal forsøges gennemført hurtigst muligt under hensyntagen til effekten af den fejlede Batchkørsel og hele Systemes tilstand.

Såfremt en Batchkørsel kun er driftsafviklet delvist, forsinket eller på anden måde fejlet, tæl- ler dette som ”Fejlede batchkørsel”.

Der skal holdes regnskab med Fejlede batchkørsel.

I Driftshåndbogen vedligeholdes en liste med Navn på Batch-jobbet, type, starttidspunkt, fre- kvens, varighed og Kategori. Som udgangspunkt er en Batchkørelse i kategori Betydende.

Eksempel på Batch-kørsler

Navn	Type	Start	Varighed (maks)	Afvik- lings- tidsrum	Frekvens	Kategori
FileClassi- fier	Skeduleret job	28-10-2014	2 timer	8.00- 16.00	Dagligt, d. 1.-15.	Bety- dende
(Automa-					hver må-
tisk data- validering)					ned

DataPa- ckage	Skeduleret job	12-02-2015	6 timer	19.30- 06.00	Dagligt	Kritisk
(Behand-
ling af da-
tapakker)

Vigtigheden af de enkelte Batchkørsler fastlægges af KOMBIT i samarbejde med Leverandø- ren inden Overtagelsesprøvens påbegyndelse, og skal fremgå af driftshåndbogen, jf. bilag

7.2.F. Leverandøren har ansvaret for en til enhver tid opdateret liste over batchkørsler og til- hørende krav.

Det må forventes at der vil være flere Batch-kørsler der kan udløse en en Incident Kategori A eller B i første del af måned.

6.1 Indplacering af Batchkørsler

Nedenfor vises Incident kategori ved fejlde gennemførelse baseret på antal gentagende fejl og kategori.

	Antal fejl siden sidst succesfuld gennemført batchkørsel
	=1	=2	>2
Kritisk	B	A	A
Betydende	C	B	A
Underordnet	C	C	B

Tabel: Incident indplacering for Batchkørsler

6.2 Servicemål for Batchkørsler

Servicemål: Ikke gennemført batchkørsel

	Indefor 24 timer	Løbende 7 dage	Løbende 30 dage
Kritisk	0	Ej relevant	Ej relevant
Betydende	1	2	3
Underordnede	2	3	4

Tabel: Servicemål for Batchkørsler

Overskridelse af en Batchkørsels servicemål, medfører oprettelse af B-incident, og følger de Servicemål, som er gældende for håndtering af Incidents.

Eksempel 1 på Incident indplacering baseret på Xxxxx gentagende fejl:

En driftsafvikling af en Underordnede Batchkørelse fejler. Leverandøren opretter en C-incident jfr. Tabel ” Incident indplacering for Batchkørsler. Batchkørsler

sættes herefter til at driftsafvikles i normal drift hvorefter der indtræder den

samme fejl på den samme Underordnede Batchkørelse. Denne skal ligeledes

oprettes som et C-incident. 3. gang samme fejl optræder i træk, skal der opret- tes en B-incident jfr. ”Tabel: Incident indplacering for Batchkørsler”.

Eksempel 2 på Incident indplacering baseret på Servicemål:

En driftsafvikling af en Betydende Batchkørelse fejler. Leverandøren opretter en C-incident jfr. Tabel ”Incident indplacering for Batchkørsler”. Systemet driftsaf-

vikles herefter i normal drift. 7 timer senere indtræder der en ny fejl på en anden Betydende Batchkørelse. Denne skal oprettes som et B-incident, da der nu har været 2 fejl inden for 24 timer jfr. ”Tabel: Servicevicemål for Batchkørsler”.

Et Incident kan lukkes ved at årsagen til fejlen er rettet eller at pågældende Bacthkørsel er gennemført succesfuld.

7 Ind og Udlæsning af Data og Datapakker

7.1 Indlæsning af Data

I forbindelse med Indlæsning af Data til Systemet skal følgende overholdes, og Indlæsningen må ikke tage længere end det altid valgte Xxxx eller den tilvalgte Option.

7.1.1 Kuber

Processering af kuber, der danner grundlag for rapportering på Administrationsportalen må ikke tage længere end valgte tid.

7.1.2 Datamarterne

Tiden regnes fra sidste leverance er modtaget i ETL processen til Datamarterne er opdate- ret jfr. valgte krav eller option.

7.1.3 Servicemål for indlæsning af Data

Fælles for ovenstående 7.1.1 -7.1.3 gælder:

• Overskridelse medføre oprettelse af en C-incident.

• 2 gentagende tidsoverskridelser medføre oprettelse af en B-incident.

• 3 eller flere overskridelser på en kalender måned, medføre oprettelse af en C-inci- dent.

7.2 Udlæsning af Data

I forbindelse med udlæsning af datapakker fra Systemet, skal følgende overholdes.

Processering af alle typer Datapakker må ikke tage længere tid end det altid valgte Xxxx eller den tilvalgte Option jfr Bilag 2.1 og Bilag 7.2.B. Dette gælder for alle lag for der er mulighed

for udlæsning af Data fx Kuber, Datamarter, EDW, DSA og Rådata.

Datapakke	Krav	Option	Målsætning
	Mbyte/Minut	Mbyte/Minut
Rådata leverance	200	1000	Maks 15 min pr udlæsning
DSA leverance	20	200
EDW leverance	25	250
Datamart leve- rance	25	250	Alle kommuner på 12 timer
Kuber leverance	500	1000	Alle kommuner på et døgn

Leverandøren skal redegøre for udlæsningstiderne i Driftsrapporteringen.

7.2.1 Servicemål for udlæsning af Datapakker

• Overskridelse af udlæsningshastigheden medfører oprettelse af en C-incident.

• 2 gentagende overskridelser på den samme Datatype medfører oprettelse af en B-in- cident.

• 3 eller flere overskridelser på en kalender måned, medfører oprettelse af en C-inci- dent.

Såfremt en kommune ikke kan indlæses datapakker fra SFTP eller tilsvarende lag (fx en di- rekte adgang til en database), skal der rejses en C-Incident.

8 Backup og Restore

Leverandøren skal sikre, at Backup og Restore gennemføres i overensstemmelse med Drifts- kontraktens punkt 13.5 og bestemmelserne i dette punkt.

Leverandøren skal i forbindelse med Backup og Restore navnlig:

• Rapportere til KOMBIT på daglig basis, hvis Backup og/eller Restore ikke gennemfø- res i overensstemmelse med planen for Backup og Restore, jf. bilag 7.2.A.1.

• Inkludere en oversigt over gennemførte og ikke-gennemførte Backup/Restore, herun- der i forhold til planen for Backup og Restore i den aftalte rapportering, jf. bilag 7.2.G. Dette gælder også Backup og Restore, som foretages af Leverandørens Underleve-

randør.

• Håndtere Backup, backupmedier og backupdata på en måde, som sikrer mulighed for gendannelse af data i tilfælde af datatab på Systemet.

• Håndtere nødvendige Restore med mindst muligt datatab og forbrug af tid.

• Fastlægge en backupproces, som sikrer optimal Backup og Restore af server, Pro-

grammel, Konfigurationsmateriale og data. Processen skal samtidigt sikre minimal ri- siko for tab af data samt processer for eventuel nødvendig gendannelse. Leverandø- ren skal ved etableringen af Backup meddele KOMBIT, hvor lang tid en Backup hhv. Restore forventes at tage.

• Opdatere procedurerne og planen for Backup og Restore kvartalsvist i forbindelse med Restore test.

• Sikre, at backupmedierne er placeret på en anden fysisk lokation end der, hvor Syste- met drives. Ved multiple datacentredrift kan backupmedier dog anbringes på det se-

kundære driftscenter.

• Sikre, at Backups, som ikke er aktuelle, arkiveres på et sikkert og et til formålet om- kostningseffektivt medie. Der skal altid mindst være 2 fulde kopier og jævnligt tages fuld Backup.

• Foretage Backup på et tidspunkt og på en måde, så det ikke er forstyrrende for drift af Systemet og/eller Brugere.

• Foretage Restore test af backupdata en gang i kvartalet, medmindre andet aftales skriftligt med KOMBIT. Testen kan foretages på Præproduktionsmiljøet.

• Minimere risikoen for, at data forsætligt eller uforsætligt går tabt ved sletning eller de- struktion, herunder således at medarbejdere involveret i udførelsen af Ydelserne ikke har adgang til både backupdata og data i Driftsmiljøet.

9 Problem Management

Leverandøren skal udføre Problem Management efter best practice på området med henblik på at forhindre fremtidige Incidents samt minimere effekten af Incidents, der ikke kan undgås.

Et afgørende element af Problem Management er, at Fejl i Ydelserne afhjælpes, så Kontrak- tens krav, herunder såvel funktionsmæssige som driftsmæssige, og forudsætninger er op-

fyldt.

Et vigtigt element af Problem Management processen er proaktiv Problem Management, hvor målet er:

• at identificere Root Causes og Problems, som ellers kunne overses.

• at identificere negative trends eller andre for Ydelserne væsentlige forhold gennem

tværgående analyse af Incidents samt brug af data fra andre processer under Drifts- kontrakten.

Af punkt 9.1 fremgår, hvilke forhold, herunder navnlig Incidents, der skal håndteres som Pro- blems, idet de nærmere Ydelser under Problem Management er beskrevet under punkt 9.2.

Leverandøren skal i forbindelse med Ydelserne under Problem Management anvende et IT Service Management system, der er beskrevet under punkt 10.2, herunder til registrering af Problems.

9.1 Problems

Problems kan identificeres blandt andet i følgende processer, hvilket medfører en oprettelse af en Problem Record, som skal behandles af Problem Management:

• 2nd and 3rd level Support

• Problem Management

• Incident Management

• Event Management

• Service Desk

Hvis Problems indrapporteres via Incident Management eller Event Management gælder, at Leverandøren straks skal oprette en Problem Record, hvis mindst et af følgende punkter er opfyldt:

1. Incidenten har eller har haft prioritet A eller B.

2. Incidenten har eller har haft prioritet C eller D, og Incidenten er eller kan være genta- gende.

3. Events, der viser en væsentlig negativ trend.

4. Udvalgte Events eller Incidents på KOMBITs anmodning, dog højst 12 om året. Events påpeget af KOMBIT, der viser en væsentlig negativ trend er omfattet af punkt 3, og

tæller dermed ikke med i de maksimale 12 Events, der kan påpeges af KOMBIT i medfør af dette punkt.

For hver Problem Record skal Problem Management identificere og håndtere de bagvedlig- gende årsager, herunder Fejl, som beskrevet under nærværende punkt 9.

Et Problem anses som indrapporteret, når en af ovennævnte processer for første gang hen- vender sig til Problem Management vedrørende håndtering af det specifikke Problem.

9.2 Ydelser under Problem Management

Leverandøren skal som led i Problem Management identificere Root Cause(s) for de Inci-

dents, der eskaleres som Problems til Problem Management, afhjælpe de Problems, som Le- verandøren er ansvarlig for, jf. punkt 9.4, samt bistå med afhjælpning af Problems, som Le-

verandøren ikke er ansvarlig for, jf. punkt 9.5.

Såfremt et Incident udspringer af flere forskellige medvirkende Problems og/eller Root Cau- ses, skal Leverandøren udføre Problem Management i forhold til samtlige Problems og Root Causes, herunder iagttage såvel de krav, der gælder for Problems, som Leverandøren er an- svarlig for, som kravene, der gælder for Problems, som Leverandøren ikke er ansvarlig for,

idet Leverandøren dog altid har pligt til at koordinere håndtering af Problems, der har sam- menhæng, så Problem Management processen optimeres, og risikoen for Incidents begræn- ses mest muligt.

Leverandørens Ydelser er generelt som følger:

• Modtagelse af indrapportering af Problem Record.

• Registrering og prioritering af Problems, jf. punkt 9.3.

• Identificering og dokumentering af Root Cause for Problems.

• Leverandøren skal, på KOMBITs anmodning, anmode Tredjepartsprogrammelleveran- dører og Anvendersystemleverandører om at få identificeret og dokumenteret Root

Cause for Problems for alle prioritet A og B Incidents, der skyldes forhold i Tredje- partsprogrammel eller Anvendersystemer.

• Sikring af afhjælpning af Problem, herunder at anmode om gennemførelse af Change gennem Change Management og Release Management, såfremt dette er påkrævet.

• Dokumentering af afhjælpningen af Problems og Root Causes. Dette omfatter at op- datere Known Error Database. Ved forebyggende vedligeholdelse skal Leverandøren oplyse arten heraf.

Leverandøren skal løbende og mindst hver anden uge orientere KOMBIT omkring status på ovenstående punkter og håndtering af alle åbne Problem Records, herunder plan for diagno- sticering og afhjælpning af Problems og Root Causes. Tilsvarende fremlægges Problem Ma- nagement status for KOMBIT ved driftsgruppemøder. Kategorisering og prioritering af Problem Records kan evt. foregå på samme møde. Der henvises til bilag 7.2.G.

9.3 Prioritering af Problems

Alle Problems prioriteres i prioritet A, B, C eller D i henhold til prioriteten for den Incident,

som det pågældende Problem har været årsag til, og som Problem Management processen er iværksat på baggrund af.

For prioriteringen gælder følgende:

• Er en Incident håndteret som en prioritet A Incident, skal det Problem, der har været årsag til den pågældende Incident, således tilsvarende prioriteres som et prioritet A Problem.

• Har et Problem været årsag til flere Incidents, prioriteres det pågældende Problem i overensstemmelse med den højest prioriterede Incident.

• Er en Incident i forbindelse med og/eller som følge af Incident Management processen nedprioriteret, skal det Problem, der har været årsag til den pågældende Incident, pri- oriteres i overensstemmelse med den højeste prioritering, der har været under Inci-

dent Management processen.

For de Problems, som ikke direkte eller indirekte er oprettet på baggrund af en Incident, gæl- der, at de prioriteres i forhold til den type incidentprioritet, som de pågældende Problems i

værste fald kunne medføre på et senere tidspunkt, såfremt de ikke afhjælpes.

Det er Leverandørens ansvar at tildele Problems prioritet i overensstemmelse med ovenstå- ende angivelser samt at vurdere, om det pågældende Problem helt eller delvist skal afhjæl- pes af tredjemand og dermed anbefale eskalation til tredjemand.

Ved uenighed om en Problem prioritering, eller hvorvidt et Problem skal løses af og ved

eskalering til tredjemand, træffer KOMBIT beslutning herom, idet Leverandøren dog i så fald kan eskalere spørgsmålet i overensstemmelse med Driftskontraktens punkt 33.2. Som alter- nativ til en eskalation i overensstemmelse med Driftskontraktens punkt 33.2, kan Parterne

aftale, at afgørelsen på Parternes uenighed udskydes, herunder med mulighed for efterføl- gende eskalation i overensstemmelse med Driftskontraktens punkt 33.2.

Indtil spørgsmålet om kategorisering af og/eller ansvaret for afhjælpning af Problems er af- gjort, skal Leverandøren håndtere det pågældende Problem i henhold til KOMBITs beslut-

ning. Viser det sig efterfølgende gennem fælles erkendelse eller den sagkyndiges afgørelse, at det pågældende Problem burde have været prioriteret og/eller afhjulpet af andre som an-

ført af Leverandøren, kan Leverandøren kræve dokumenterede meromkostninger, herunder i forbindelse med nødvendiggjort merarbejde, som følge af KOMBITs fejlagtige prioritering

og/eller ansvarsplacering, dækket af KOMBIT, idet det dokumenterede merarbejde betales i overensstemmelse med Driftskontraktens bestemmelser om udførelse af timebaserede res- sourcer.

9.4 Problems, som Leverandøren er ansvarlig for

For alle Problems, herunder Fejl, som Leverandøren er ansvarlig for, skal Leverandøren af- hjælpe de pågældende Problems inden for afhjælpningstiderne, jf. punkt 9.4.1. Dette gælder uanset, om et Problem skyldes Fejl i Programmel, i Konfigurationsmateriale, i Leverandørens Ydelser og/eller forhold i øvrigt, som Leverandøren er ansvarlig for.

Efter afhjælpning af Problems skal såvel Systemet i Driftsmiljøet som Leverandørens øvrige Ydelser således opfylde Kontraktens krav, herunder således at konstaterede Fejl er afhjulpet.

9.4.1 Servicemål for afhjælpning af Problems

Problems skal afhjælpes inden for den afhjælpningstid, der gælder for prioriteten af det på- gældende Problem, medmindre andet aftales.

Servicemål for Problem Management
Afhjælpningstider	Servicemål
Tid til afhjælpning Prioritet A Problem	15 Arbejdsdage
Tid til afhjælpning Prioritet B Problem	30 Arbejdsdage
Tid til afhjælpning Prioritet C Problem	90 Arbejdsdage
Tid til afhjælpning Prioritet D Problem	180 Arbejdsdage

Tabel 7 Servicemål for afhjælpning af Problems

Afhjælpningstiden er tiden fra indrapportering af et Problem, jf. punkt 9.1, til Leverandøren har afhjulpet det pågældende Problem i Systemet i Driftsmiljøet, medmindre andet aftales.

9.5 Problems, som Leverandøren ikke er ansvarlig for

For de Problems, som Leverandøren ikke er ansvarlig for, herunder fejl i Tredjepartsprogram- mel og fejl i Anvendersystemer, skal Leverandøren proaktivt følge op på status og rapportere herpå ved driftsgruppemøder, jf. punkt 9.2.

Leverandøren skal herunder gøre nødvendige tiltag for at minimere risikoen for, at det på- gældende Problem medfører nye Incidents.

9.6 Servicemål for Root Cause Analyser

Det er et Servicemål, at en orientering indeholdende Root Cause Analyse for prioritet A og B Problems i 95 % af alle tilfælde per kalendermåned skal være KOMBIT i hænde senest 5 Ar- bejdsdage efter det pågældende Problem er konstateret. Et Problem betragtes senest som

konstateret ved det førstkommende af følgende tidspunkter:

• Problem er indrapporteret

• Problem Record er oprettet

• Senest 2 Dage efter starttidspunktet for Incidenten (kun for Problems relateret til Root Cause for Incidents af varighed over 48 timer)

Dog gælder det, at såfremt årsagen til Problemet ikke er Leverandørens ansvar, og færdiggø- relse af Root Cause Analyse forsinkes grundet afventning af Tredjepartsprogrammelleveran- dører, Anvendersystemleverandører eller Anvendere, kan Leverandøren ikke gøres ansvarlig for forsinkelse ved levering af RCA. I stedet skal Leverandøren inden for Servicemålet anføre en plan for indhentning af RCA-oplysninger fra Tredjepartsprogrammelleverandører, Anven- dersystemleverandører eller Anvendere.

10 Service Desk

Supportansvaret omfatter at give supportberettigede Brugere, KOMBIT, KOMBITs repræsen- tant samt Anvendersystemleverandører adgang til en effektiv Service Desk, der kan håndtere alle relevante henvendelser samt sikre opfølgning herpå overfor den person, der har hen-

vendt sig.

Leverandøren skal levere følgende Ydelser i forbindelse med Service Desk:

• Etablere og vedligeholde en supportorganisation, jf. punkt 10.1

• Modtagelse og håndtering af henvendelser om Incidents, jf. punkt 10.4

• Etablering, vedligeholdelse og anvendelse af IT Service Management system, jf. punkt 10.2

• Modtagelse og håndtering af henvendelser om Service Requests, jf. punkt 11

• Levere dataudtræk over supporthenvendelser, jf. punkt 10.5

• Oprette, nedlægge og administrere supportberettigede Brugere af Service Desk

• For så vidt angår hjælp til anvendelse af Systemet ydes denne service kun i Service Desken åbningstid.

• Leverandøren skal stille funktionalitet til rådighed for kommunerne og KOMBIT til lø- bende at opdatere informationen om de Supportberettigede brugere.

10.1 Supportorganisation

Leverandøren skal etablere en supportorganisation, herunder Service Desk, i overensstem- melse med processerne og anbefalingerne i ITIL v3 eller tilsvarende.

Leverandøren skal levere følgende Ydelser i relation til supportorganisationen:

• 1st Level Support som en del af Service Desk. Dette omfatter at modtage og håndtere henvendelser og følge op over for den person, der har henvendt sig om support. Fo-

kus i 1st Level Support er typisk modtagelse af henvendelsen og opfølgning herpå. 1st Level Support varetages typisk af fagpersonale hos Leverandøren med særlige kompetencer inden for håndtering af henvendelser, herunder hjælp til anvendelse af systemet

• Leverandøren skal fra 1st Level Support efter behov delegere til 2nd Level Support og følge op herpå i forbindelse med håndteringen af Incidents og Service Requests.

• 2nd Level Support på Driftsmiljøet, netværksopkoblinger fra Driftsmiljøet til internettet, samt de dele af Systemet, som Leverandøren har supportansvar for, overfor egen 1st Level Support. Fokus i 2nd Level Support er Omgåelse og afhjælpning, fx for Fejl ved Infrastruktur og Programmel leveret af Leverandøren. Denne type opgaver varetages

typisk af fagpersonale hos Leverandøren med særlige kompetencer inden for disse områder.

• Såfremt Anvendersystemleverandører eller Tredjepartsprogrammelleverandører ikke lever op til de aftaler, de har indgået med KOMBIT, er Leverandøren forpligtet til at

følge op overfor de(n) pågældende leverandør(er) samt rapportere skriftligt til KOMBIT om den manglende opfyldelse. KOMBIT er ansvarlig for at sikre det nødvendige afta-

legrundlag med de pågældende leverandører og vil give Leverandøren en overordnet orientering om de dele af aftalerne, der har relevans i forhold til Driftskontrakten.

Leverandører af henholdsvis Anvendersystemer og Tredjepartsprogrammel leverer support

på henholdsvis deres respektive Eksterne Snitflader for Integrationer og Tredjepartsprogram- mel, hvilket dog ikke fritager Leverandøren for sit opfølgningsansvar, jf. punkt 1.

Service Desk skal håndtere henvendelser og yde support til supportberettigede Brugere, KOMBITs repræsentanter samt Anvendersystemleverandører. De supportberettigede Bru- gere er navngivne brugere i kommunerne.

Følgende enkelte kontaktpunkt hos Leverandøren skal kunne anvendes i forbindelse med kontakt til Service Desk, jf. punkt 10.

[Tilbudsgiver udfylder]

Tlf. Mail

Tabel 8: Kontaktpunkt til Service Desk hos Leverandøren

10.2 IT Service Management system

Leverandøren skal som en del af Driftskontrakten stille et IT Service Management system til rådighed for Service Desk til registrering og opfølgning på henvendelser om Incidents, Pro- blems, Changes og Service Requests. Alle henvendelser til Service Desk registreres heri og prioriteres i den forbindelse som enten et Service Request, et Problem, en Change eller en

Incident.

IT Service Management systemet, der stilles til rådighed af Leverandøren, skal bl.a. under- støtte følgende funktionalitet:

• Adgang til information om og statistik på alle registrerede Incidents, Problems, Chan- ges og Service Requests

• Registrering af følgende information:

o Registrering af Incidents, Problems, Changes og Service Requests skal om- fatte informationer, som angivet under punkt 4, punkt 9 og punkt 11.

o Aktivitetslog

o Log over delegeringer og eskaleringer

o Tidspunkt for lukning af Incidents, Problems, Changes eller Service Requests med angivelse af den løsning, Omgåelse eller afhjælpning, der er gennemført, og/eller vejledning, der er givet

Herudover skal Leverandøren gøre det muligt at foretage indrapportering af Incidents, Pro-

blems, Changes og Service Requests via brugergrænseflade for supportberettigede Brugere. Efter indrapportering skal IT Service Management systemet returnere bekræftelse med angi-

velse af unikt sags id. Supportberettigede Brugere skal kunne se og tilgå egne indrapporte- rede Incidents og Service Requests, såvel som ved søgning på sags id for Incidents og Ser-

vice Requests indrapporteret af andre Brugere indenfor samme respektive administrative en- hed.

Leverandøren skal anvende et IT Service Management system, som har en snitflade, der kan integreres til fra eksterne IT Service Management systemer, og stille snitfladen til rådighed

for KOMBIT eller en repræsentant for KOMBIT.

Såfremt KOMBIT stiller et IT Service Management system til rådighed for Leverandøren, er Leverandøren forpligtet til at anvende dette til fyldestgørende registrering og opfølgning på henvendelser om Incidents, Problems, Changes og Service Requests. Det skal være muligt for Leverandøren at anvende dette via såvel en brugergrænseflade som en snitflade. Leve- randøren har mulighed for at integrere eget IT Service Management system til KOMBITs IT Service Management system via snitfladen med henblik på registrering og opfølgning på

Incidents, Problems, Changes og Service Requests.

Der ydes ikke særskilt vederlag for Leverandørens timer eller merudgifter til implementering og drift af integrationer mellem Leverandørens IT Service Management system og eksterne IT Service Management systemer.

10.3 Systemets dertil indrettede hjemmeside

For at sikre tilstrækkelig information til Systemets Anvendere er Leverandøren ansvarlig for at levere webservice, passende design af og indhold til en dertil indrettet hjemmeside.

På hjemmesiden forefindes driftsrelevant samt anden systemrelevant information. Hjemmesi- den designes i samarbejde med KOMBIT. KOMBIT skal kunne tilgå og opdatere dele af

hjemmesiden med fx kommunerettet information eller uddannelsesmateriale.

Det er leverandørens ansvar, at følgende information opdateres på den dertil indrettede hjemmeside:

• Systemets og Driftsmiljøets aktuelle overordnede driftsstatus, jf. punkt 1

o Ved prioritet A og B Incidents skal kritiske forhold om Incidenten formidles,

sammen med tydelig angivelse af Incident start og tidspunkt for seneste opda- tering af status for Incidenten, samt med løsningstidspunkt når det er løst

• Aktuel status på:

o Miljøer, jf. 7.2.C, tilgængeligt for Anvendere

o Integrationer til Afsendersystem(er) skal vises

• Kendte Fejl, som berører Anvendernes mulighed for at arbejde problemfrit i Systemet og Driftsmiljøet skal være beskrevet med status på Fejl og evt. løsningshorisont (fx

med angivelse af release og dato, hvor Xxxx forventes udbedret)

• Omgåelse til kendte Fejl skal være beskrevet, så det er muligt for Anvenderne at an- vende Systemet og Driftsmiljøet med så få gener som muligt

• Information og varsling om kommende Changes og Patches til og Versioner/versioner af Systemet og Driftsmiljøet

• Information om konkrete videreudviklingstiltag med tilhørende plan for implementering

• Seneste og foregående release noter til Systemet og Driftsmiljøet

• Varsling ved genetablering af Eksternt Testmiljø, jf. punkt 17

• Anden relevant support information til Systemets Anvendere, fx betingelser for anven- delse af Service Desk

• Abbonering på relevant info der er knyttet op til ens brugerprofil fx aktuel kommune information om forsinkelser eller fejl i data

KOMBIT har ansvar for indkøb og løbende fornyelse af supporthjemmesidens DNS navn. KOMBIT kan vælge også at udbyde webservice og/eller design af siden. I dette tilfælde vil

Leverandøren fortsat skulle opdatere den dertil indrettede hjemmesides indhold som angivet i dette afsnit eller efter aftale med KOMBIT.

10.4 Servicemål for Service Desk

Servicemålene for Service Desk er beskrevet i Tabel 9 nedenfor.

Servicemål for Service Desk
Område	Definition	Servicemål	Måling
Åbningstid for Service Desk	Tidsrummet hvor Service Desken er bemandet og åben for besvarelse af henvendelser	For telefonhenvendelser: Arbejdsdage 8-16 For henvendelser via mail og webformular: Målepe- riode 1	Måles og dokumente- res af Leverandøren
Telefonhenven- delser	Henvendelser til Le- verandørens Service Desk via telefon.	Personen, som henven- der sig, må ikke blive mødt af en optagettone. Den gennemsnitlige tele- fonventetid må ikke over- stige 3 minutter over en kalendermåned. Telefonventetiden må for hvert enkelt opkald ikke overstige 10 minutter.	Dokumenteres af Le- verandøren i telefonsy- stemet.
Henvendelser via mail og webfor- mular	Henvendelser til Le- verandørens Service Desk via mail eller webformular.	Personen, der henvender sig indenfor service de- skens åbningstid, skal modtage en personlig re- aktion på henvendelsen inden for 2 timer – enten med løsning eller med be- sked på, hvordan og hvornår henvendelsen vil blive håndteret. Hvis be- svarelsestiden falder uden uden for servicedi- skens åbningstid, fortsæt- ter tiden førstkommende arbejdsdag	Dokumenteres i Leve- randørens IT Service Management system.
Afslutning af sa- ger i 1st Level Support	1st Level Support er den support, som umiddelbart kan	65 % af alle henvendelser opgjort for en kalender- måned af gangen skal	Dokumenteres i Leve- randørens IT Service Management system.

Servicemål for Service Desk

Område

Definition

Servicemål

Måling

ydes af Service Desk overfor den person, der henvender sig.

være afsluttet ved første henvendelse i Service

Desk.

Tabel 9: Servicemål for Service Desk

For telefoniske henvendelser er telefonventetiden den tid, der går fra, der er telefonisk forbin- delse til telefonsystemet hos Service Desk, og til personale hos Service Desk besvarer op-

kaldet og påbegynder modtagelse af henvendelsen. Såfremt Leverandøren anvender en tele- fonsluse går telefonventetiden fra det tidspunkt, hvor brugeren har valgt personlig henven-

delse.

Leverandøren er på anmodning fra KOMBIT forpligtet til at give KOMBIT indsigt i Leverandø- rens målinger for Servicemål for Service Desk.

10.4.1 Option på udvidelse af Service Deskens åbningstid (Option 1)

Leverandøren har i bilag 7.2.B angivet en pris på Option for udvidelse af Service Deskens åbningstid, jf. nedenstående beskrivelse:

Servicemål for Service Desk
Område	Definition	Servicemål	Måling
Option på udvidet	Tidsrummet hvor	Leverandørens Service	Måles og dokumente-
åbningstid for	Service Desken er	Desk skal have følgende	res af Leverandøren
Service Desk for	bemandet og åben	åbningstider: 24/7
telefonhenvendel-	for besvarelse af op-
ser	kald

Tabel 10: Option på udvidelse af Service Deskens åbningstid

10.5 Dokumentation af henvendelser til Service Desk

Leverandøren skal månedligt og i øvrigt på KOMBITs anfordring levere et udtræk af data fra Service Desk over supporthenvendelser, herunder evt. vederlagsberettigede supporthenven- delser.

11 Request Fulfilment

Leverandøren skal som en del af Request Fulfilment processen varetage alle henvendelser i form af Service Requests, der udgør forespørgsler om information eller gennemførsel af for- udgående aftalte Standard Changes eller bestilling og håndtering af eventuelle standardydel- ser.

Leverandøren skal levere følgende Ydelser i forbindelse med Request Fulfilment:

• Udarbejde og vedligeholde et servicekatalog indeholdende oversigt over Request Ful- filment ydelser, herunder standardydelser, med fastsatte Servicemål for reaktionstid

og løsningstid

• Modtagelse af og besvarelse af henvendelser om Service Requests, jf. punkt 10

• Registrering af henvendelsen til Service Desk som en Service Request, jf. punkt 10

• Klassificering af henvendelser om Service Requests for efterfølgende at kunne identi- ficere relevante indsatsområder med henblik på at reducere antallet af henvendelser om Service Requests

• Afklaring og besvarelse af forespørgsler om information relateret til anvendelsen af Systemet

• Gennemføre forhåndsgodkendte Standard Changes

• Initiere Change Management processen baseret på henvendelse om anmodning om gennemførelse af en Change

Forhåndsgodkendelse af Standard Changes foretages i Change Advisory Board, jf. bilag

7.2.G. Derefter skal de godkendte Standard Changes ikke godkendes enkeltvis af Change

Advisory Board, men kan udføres af Service Desk i overensstemmelse med forhåndsgodken- delsen.

11.1 Indrapportering af information om Service Requests

Leverandøren skal sikre, at der i forbindelse med henvendelser om Service Requests til Ser- vice Desk som minimum indrapporteres følgende information:

• Tidspunkt for modtagelsen af Service Request

• Formål med den pågældende Service Request

• Identifikation af den person og organisation, der har henvendt sig

• Kontaktperson i organisationen, der indrapporterer den pågældende Service Request

• Beskrivelse af den pågældende Service Request, herunder hvilken Ydelse, der øn- skes udført

• Eventuelle bilag til belysning af den pågældende Service Request Oplysningerne indrapporteres i IT Service Management systemet.

11.2 Servicemål for Service Requests

Leverandørens ydelser omfatter Request Fulfilment ydelser med fastsatte Servicemål for re- aktionstid og løsningstid. Leverandøren skal uden unødigt ophold registrere og håndtere Ser- vice Requests.

Reaktionstiden er tiden, der må gå, fra bestilling, til Leverandøren skal have påbegyndt udfø- relsen af opgaven.

Løsningstid er tiden, der må gå, fra bestilling, til Leverandøren skal have leveret Service Requesten endeligt og i overensstemmelse med kravene til Service Requesten.

For Request Fulfilment ydelser, hvor Leverandøren ikke har angivet et specifikt Servicemål i servicekataloget, er kravet til løsningstid 3 Arbejdsdage.

Leverandøren skal levere udkast til et Servicekatalog. Servicekataloget skal være udarbejdet og godkendt inden Driftsprøvens begyndelse. Servicekataloget kan udvides med nye og/eller ændrede Request Fulfilment ydelser samt dertilhørende Servicemål.

KOMBIT har krav om følgende standardydelser beskrevet under punkt 11.2.11- 10.2.5 om Service Requests. Alle Standardydelserne kan bestilles af KOMBIT.

11.2.1 Udarbejdelse af en ISAE 3402 type 2 revisionserklæring (udover den ene som er en del af det faste vederlag)

Service Request	3402 type 2 revisionserklæring
Kort beskrivelse	Leverandøren skal udarbejde en ISAE 3402 type 2 erklæring efter øn- ske fra KOMBIT i henhold til punkt 26.2. Erklæringen skal følge ret- ningslinjerne for indhold nævnt i punkt 26.2.
Pris	Særskilt betalbar ydelse, jf. bilag 7.2.B
Servicemål	• Reaktionstid: 5 Arbejdsdage • Løsningstid: 90 dage

11.2.2 Opsæt og nedtag Supplerende Testmiljø

Service Request	Opsæt og nedtag Supplerende Testmiljø
Kort beskrivelse	Leverandøren skal ved bestillingen af denne standardydelse klargøre et miljø til at foretage afprøvning, jf. bilag 6. Når KOMBIT har bestilt denne standardydelse, skal Leverandøren levere følgende Ydelser: • Leverandøren skal opsætte og vedligeholde et testmiljø, som skal anvendes til afprøvning af Systemet, jf. bilag 6 • Leverandøren skal installere nødvendigt programmel til anven- delse af Systemet i testmiljøet • Leverandøren skal oprette brugere, som skal have adgang til Sy- stemet i testmiljøet • Leverandøren skal indlæse data i Systemet i testmiljøet på bag- grund af udtræk fra Systemet i Produktionsmiljøet eller fra en an- den kilde anvist af KOMBIT. Data skal kunne anonymiseres. • Leverandøren skal efter aftale med KOMBIT nedtage testmiljøet, herunder slette data. Testmiljøet vil være bestilt af KOMBIT til et bestemt formål. Det skal være muligt for kommunerne at anvende testmiljøet fra kommunernes IT-miljø eller fra en af KOMBIT anvist lokation, som er kompatibel her- med. Efter første opsætning af miljøet i denne standardydelse skal Leveran- døren udføre og bestå en installationstest, jf. bilag 6.
Pris	Særskilt betalbar ydelse, jf. bilag 7.2.B
Servicemål	• Reaktionstid: • Løsningstid opsætning: 15 Arbejdsdage • Løsningstid nedtagning: 5 Arbejdsdage

Service Request	Opsæt og nedtag Supplerende Testmiljø

11.2.3 Genbestilling af data

Genbestiling af Data
Kort bekrivelse	Genbestiling af tidligere fremsendte data
Pris	Særskilt betalbar ydelse, jf. bilag 7.2.B
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal udføres senest 2 Arbejdsdage efter bestilling

11.2.4 Opsæt Integration til andet system

Service Request	Ny integration
Kort beskrivelse	Leverandøren skal ved bestilling af denne standardydelse tilkoble et konkret Anvendersystem til Systemet og i denne forbindelse yde støtte til Anvendersystemleverandør og KOMBIT i opsætning og teststøtte. Leverandøren skal således efter bestillingen oprette Integration mellem et Anvendersystem og Systemet i Driftsmiljøet. Dette omfatter: • Etablering af teknisk adgang for Anvendersystemet til Systemet i Driftsmiljøet, herunder Produktionsmiljøet og Eksternt Testmiljø, konfiguration af firewalls, porte, og andet hardware. • Assistere med oprettelse af tilslutnings- og serviceaftale, gæl- dende for alle services fra Systemet i Driftsmiljøet • Oprette Anvendersystemleverandør i IT Service Management sy- stemet, således at disse kan oprette Incidents, Service Requests mv. Efter oprettelsen af teknisk adgang, skal Leverandøren deltage i Anven- dersystemets test og rådgivning af Anvendersystemleverandøren i et ri- meligt omfang, dog maksimalt 1 mandedag (forstået som 8 timer).
Pris	Særskilt betalbar ydelse, jf. bilag 7.2.B
Servicemål	• Reaktionstid: 5 Arbejdsdage • Løsningstid: 20 Arbejdsdage

11.2.5 Hypercare

Service Request

Hypercare periode

Kort beskrivelse

Hypercare betyder, en dag, hvor KOMBIT kan kræve en særlig be- vågenhed og dermed udvidet servicemål af driften af FLIS.

Hypercaredagen kan bestilles med et varsel på en måned, og ved

bestillingen kan KOMBIT oplyse, om der er tale om et enkeltstående

tilfælde eller en længerevarende periode med x-antal dage om må- neden. I tilfælde af sidstnævnte kan KOMBIT afbestille hypercare med et varsel på en måned.

Leverandøren skal i forbindelse med hypercare ud over de angivne Servicemål i Bilag 7.2 kunne iværksætte afhjælpning af Inicidents med en reaktionstid på 30 min., Eskalationstid på 30 min. og en

Løsningstid på 120 min. i tidsrummet 08.00-17.00.

Pris

Særskilt betalbar ydelse, jf. bilag 7.2.B

Servicemål

• Reaktionstid: 5 Arbejdsdage

• Løsningstid: 20 Arbejdsdage

KOMBIT har krav om nedenstående standardydelser som kan bestilles et ubegrænset antal gange. For Standardydelserne vil Leverandøren modtage en engangsbetaling, som er den fulde betaling for standardydelserne nedenfor.

11.2.6 Udtræk fra IT Service Management systemet

Service Request	Udtræk af f.eks. oversigt over Incidents, Changes, Problems, Service Requests
Kort beskrivelse	Udtrækket dannes i IT Service Management systemet ud fra parametre angivet af KOMBIT.
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal leveres til KOMBIT i et Excel format senest 2 Arbejdsdage efter bestilling

11.2.7 Udtræk fra overvågningssystemerne

Service Request	Udtræk af f.eks. oversigt over alarmer, alarmpunkter, svartidsmålinger, stikprøvemålinger, kontrolmålinger samt driftseffektivitetsmålinger.
Kort beskrivelse	Udtrækket bearbejdes af leverandøren til et maskinlæsbart format fx CSV eller Excel ud fra parametre angivet af KOMBIT.
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal leveres til KOMBIT i et Excel format senest 2 Arbejdsdage efter bestilling

11.2.8 Udtræk fra Service Desk

Udtræk fra Ser- vice Desk
Kort bekrivelse	Leverandøren skal på KOMBITs anmodning give adgang til alle infor- mationer om alle registrerede Incidents, Problems og Service Requests.
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag

• Løsningstid: Skal udføres senest 3 Arbejdsdage efter bestilling

11.2.9 Ændring af Kontaktoplysninger

Ændring af kon- taktperson
Kort bekrivelse	Ændring af kontaktoplysninger og adgang for brugre i og af systemet
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal udføres senest 2 Arbejdsdage efter bestilling

11.2.10 Tilgå egne data

Udarbejde snit- flader til kom- munerne
Kort bekrivelse	Leverandøren skal udarbejde snitflader til kommunerne, så de kan tilgå data for egen kommune fra rådata, DSAHIST- eller Datamartlaget jfr. Krav 2.1-1
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal udføres senest 2 Arbejdsdage efter bestilling Udlæsningstiden er specificeret ved de hastigheder, som er angivet i krav til bilaget.

11.2.11 Tilgå logningsdata

Udlevering af re- levante log- ningsdata
Kort bekrivelse	Leverandøren skal udarbejde informationer om Personfølsome log- ningsdata (Revisionslog) når de efterspørgers fra Kommunerne
Pris	Ej særskilt betaling
Servicemål	• Reaktionstid: 1 Arbejdsdag • Løsningstid: Skal udføres senest 3 Arbejdsdage efter bestilling

12 Access Management

Leverandøren skal som en del af Access Management til Driftsmiljøet håndtere korrekte ad- gange og rettigheder til Leverandørens medarbejdere.

Leverandøren skal levere følgende ydelser:

• Modtage og behandle forespørgsler om tildeling af rettigheder i henhold til gældende regler fastlagt under Information Security Management

• Tildele og fjerne rettigheder

• Tilsikre, at behørig Monitorering og kontrol af, at rettigheder er opsat i Driftsmiljøet

• Oprette, nedlægge og administrere godkendte Brugere i Service Desk

• Etablering adgang til det Eksterne Testmiljø for myndigheder og leverandører

• Udførelse af et årligt review af tildelte rettigheder og distribuering af rapporten til KOMBIT

13 Servicemål for drift

[Punkt 13 med underpunkter udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]

Leverandørens driftsydelser består overordnet i følgende:

• Driftsafvikling af Systemet i Driftsmiljøet, jf. bilag 7.2.C, herunder sikre korrekt ekse- kvering af dataoverførsler i forbindelse med Integrationer til Anvendersystemer.

• Agere proaktivt og sikre høj driftsstabilitet og et højt serviceniveau, herunder sikre at Brugerne af Systemet oplever høj kvalitet ved anvendelse af Systemet.

• Sikring af, at der føres regnskab over målt driftseffektivitet og svartider med henblik på driftsrapportering, jf. bilag 7.2.G.

Servicemål for driftsafvikling som beskrevet i punkt 13 og underpunkter er opdelt i Service- mål for Applikationsdrift, jf. punkt 13.1, Servicemål for Infrastrukturdrift, jf. 13.2, en opgørelse

af Kombineret Tilgængeligheds Servicemål, jf. punkt 13.3, en opgørelse af Systemets bruger- oplevede driftseffektivitet, jf. punkt 13.4, samt en opsummering af Servicemålene i punkt 13.1 og 13.2 i punkt 13.5.

Fælles for opgørelsen af både Applikationsdrift og Infrastrukturdrift gælder følgende. Den "Aftalte Driftstid" er hele Måleperiode 1.

Den ”Tilgængelige Driftstid” og ”Aftalte Driftstid” måles i hele minutter.

Driftseffektiviteten opgøres i procent med to decimalers nøjagtighed.

Tid i aftalte servicevinduer fraregnes i Tilgængelig Driftstid og Aftalt Driftstid. Såfremt Leve-

randøren anvender mere tid til servicevinduet end aftalt, jf. servicevinduerne i punkt 18.5, fra- går den for meget anvendte tid i den Tilgængelige Driftstid.

Leverandøren skal måle og månedligt rapportere på driftseffektiviteten i henhold til ovenstå- ende bestemmelser.

Leverandøren skal sørge for, at der føres regnskab over opnået driftseffektivitet, som indbe- rettes som en del af driftsrapporteringen, jf. bilag 7.2.G.

Driftseffektiviteten måles for Systemet som helhed og driftseffektivitetsprocenten opgøres så- ledes per miljø:

Tilgængelig Driftstid x 100 %

Aftalt Driftstid

Ved ”Tilgængelig Driftstid” forstås, at hele Systemet kan anvendes til normal driftsafvikling herunder uden driftsforstyrrelser i form af Prioritet A Incidents eller Prioritet B Incidents, jf.

punkt 4.2. Tidsrum, hvor der er Prioritet A Incidents eller Prioritet B Incidents fragår således i Tilgængelig Driftstid.

Herudover fragår tidsrum fra Tilgængelig Driftstid, hvor Leverandørens forhold indebærer en unødig forhaling af løsningen på en Incident, jf. punkt 4.2, hvor Leverandøren ikke eller kun delvis er ansvarlig for årsagen.

Der skal ved enhver driftsforstyrrelse i tilgængeligheden som følge af Prioritet A Incidents el- ler Prioritet B Incidents fratrækkes minimum 5 minutter i Tilgængelig Driftstid, idet al yderli- gere driftsforstyrrelse opgøres per påbegyndt minut, driftsforstyrrelsen varer.

I tilfælde af, at fejlfri driftsafvikling ikke kan opretholdes som følge af en driftshindring, som KOMBIT og/eller KOMBITs øvrige leverandører er ansvarlig for (eksempelvis fejl i Anvender- systemer eller i andre systemer, som Leverandøren ikke er ansvarlig for), udefra kommende driftsforstyrrelser (nedetid på forbindelsen til de offentlige registre, hvor der foretages opslag og berigtigelser mv.), fragår dette ikke i den Tilgængelige Driftstid.

Dette gælder tilsvarende, hvis KOMBIT ikke har opfyldt sine forpligtelser under Kontrakten, og dette dokumenterbart – som eneste årsag - har medført, at fejlfri driftsafvikling ikke har

kunnet opretholdes og/eller genetableres. I sådanne tilfælde fragår den dokumenterede peri- ode ikke i den Tilgængelige Driftstid.

Leverandøren har bevisbyrden for, at en driftsforstyrrelse skyldes forhold, som Leverandøren ikke er ansvarlig for.

Driftsforstyrrelser regnes fra det tidspunkt, hvor Leverandøren konstaterer eller burde have konstateret en Prioritet A Incident eller Prioritet B Incident, og indtil normal driftsafvikling er genetableret i form af, at de(n) pågældende Incident(s) er løst, jf. punkt 4.10. For så vidt an- går driftsforstyrrelser, som andre er ansvarlige for, men som forlænges og/eller forværres

som følge af Leverandørens forhold, regnes Leverandørens ansvar for driftsforstyrrelsen fra det tidspunkt, hvor Leverandøren burde have handlet i forhold til Incidenten, og indtil Leve- randøren har handlet.

Hvis der opstår flere på hinanden følgende Incidents fragår perioden mellem to på hinanden følgende Prioritet A eller Prioritet B Incidents i Tilgængelig Driftstid, hvis perioden er kortere end varigheden af den sidste Incident. Dette gælder dog ikke, hvis perioden mellem to på

hinanden følgende Incidents er længere end 60 minutter.

13.1 Servicemål for Applikationsdrift

13.1.1 Servicemål for driftseffektivitet for Applikationsdrift

Systemet i Produktionsmiljøet, Præproduktionsmiljøet og Eksternt Testmiljø skal driftsafvikles hele døgnet alle Dage bortset fra, når der udføres ændringer i servicevinduer, jf. punkt 18.5.

Applikationsdrift

Måleperiode 1

Servicemål for driftsef- fektivitet for Systemet per miljø
Produktionsmiljøet	99,9 %
Præproduktionsmiljøet	95,0 %
Eksternt Testmiljø	98,0 %

Tabel 11 Oversigt over Servicemål for Applikationsdrift

13.1.2 Måling af driftseffektivitet for Applikationsdrift

Dog bemærkes det, at tidsrum med prioritet A eller B Incidents som følge af for lange svarti- der ikke fragår i Tilgængelig Driftstid, jf. punkt 14.3.5 og 0. Tidsrum med for lange svartider

fragår i stedet i Tilgængelig Driftstid i overensstemmelse med det i punkt 14.3.6 og 0 anførte Eksempel på beregning 1:

En driftsforstyrrelse forårsaget af en Prioritet B Incident varer 29 minutter. Systemet driftsafvikles herefter i normal drift i 20 minutter, hvorefter der indtræder en ny drifts-

forstyrrelse i form af en Prioritet A Incident, som varer 38 minutter. I dette eksempel er den mellemliggende periode med normal drift kortere end den efterfølgende driftsfor- styrrelse og samtidig kortere end 60 minutter. Derfor regnes driftsforstyrrelsen som 29 minutter + 20 minutter + 38 minutter, i alt 87 minutter, dvs. der skal fragå 87 minutter i den Tilgængelige Driftstid.

Eksempel 2:

En driftsforstyrrelse forårsaget af en Prioritet B Incident varer 120 minutter. Systemet driftsafvikles herefter i normal drift i 40 minutter, hvorefter der indtræder en ny drifts-

forstyrrelse i form af en Prioritet A Incident, som varer 38 minutter. I dette eksempel er den mellemliggende periode med normal drift kortere end 60 minutter, men længere

end den efterfølgende driftsforstyrrelse. Derfor regnes driftsforstyrrelsen som 120 mi- nutter + 38 minutter, i alt 158 minutter, dvs. der skal fragå 158 minutter i den Tilgæn- gelige Driftstid.

13.2 Servicemål for Infrastrukturdrift

13.2.1 Servicemål for driftseffektivitet for Infrastrukturdrift

Produktionsmiljøet, Præproduktionsmiljøet og Eksternt Testmiljø skal driftsafvikles hele døg- net alle Dage bortset fra, når der udføres ændringer i servicevinduer, jf. punkt 18.5.

Infrastrukturdrift Servicemål for driftseffektivitet per miljø	Måleperiode 1
Produktionsmiljøet	99,9 %
Præproduktionsmiljøet	95,0 %
Eksternt Testmiljø	98,0 %

Tabel 12 Servicemål for driftseffektivitet for Infrastrukturdrift

13.3 Kombineret Tilgængeligheds Servicemål

Leverandøren skal månedsvis opgøre og rapportere på det Kombinerede Tilgængeligheds Servicemål (KTS), jf. bilag 7.2.B punkt 9.

KTS omfatter et kombineret Infrastrukturdrift og Applikationsdrift Servicemål for den totale driftseffektivitet på Produktionsmiljøet. KTS for Systemet opgøres på følgende måde:

Måleperiode 1 for Produktionsmiljøet:

(Opgjort driftseffektivitet for Applikationsdrift i henhold til punkt 13.1.2 i % + opgjort driftsef- fektivitet for Infrastrukturdrift i henhold til punkt 0 i %) – 100 % = KTS i %.

13.4 Systemets brugeroplevede driftseffektivitet

Leverandøren skal månedsvis opgøre og rapportere på Systemets brugeroplevede driftsef- fektivitet for Applikationsdrift og Infrastrukturdrift, både individuelt og samlet for henholdsvis

Produktionsmiljø, Præproduktionsmiljø og Eksternt Testmiljø for henholdsvis Måleperiode 1.

Systemets brugeroplevede driftseffektivitet er udtryk for oplevelsen af den samlede drift set fra Anvendernes synspunkt, og der sondres derfor ikke mellem, om en driftshindring skyldes forhold, som Leverandøren er ansvarlig for eller ej.

Systemets oplevede driftseffektivitet for Applikationsdrift og Infrastrukturdrift opgøres således per miljø:

Tilgængelig Driftstid x 100 %

Aftalt Driftstid

Ved ”Tilgængelig Driftstid” forstås, at hele Systemet kan anvendes til normal driftsafvikling herunder uden driftsforstyrrelser i form af prioritet A Incidents eller prioritet B Incidents, jf. punkt 1. Tidsrum, hvor der er prioritet A Incidents eller prioritet B Incidents fragår således i Tilgængelig Driftstid. Dette gælder også ved prioritet A Incidents eller prioritet B Incidents, hvor Leverandøren ikke eller kun delvis er ansvarlig for årsagen.

Ved opgørelse af Systemets brugeroplevede driftseffektivitet for den samlede effekt af Appli- kationsdrift og Infrastrukturdrift gælder, at samtidige tidsrum med driftsforstyrrelser for Appli- kationsdrift og Infrastrukturdrift ikke adderes.

13.5 Oversigt over Servicemål for Applikationsdrift og Infra- strukturdrift

Indeværende afsnit er en opsummering af Servicemålene fra punkt 13.1 og 13.2 samt deres underpunkter.

Servicemål fra Applikationsdrift, jf. punkt 13.1:

Applikationsdrift

Servicemål for

Måleperiode 1

driftseffektivitet for Sy- stemet per miljø
Produktionsmiljøet	99,9 %
Præproduktionsmiljøet	95,0 %
Eksternt Testmiljø	98,0 %

Servicemål fra Infrastrukturdrift, jf. punkt 13.2:

Infrastrukturdrift Servicemål for driftseffektivitet per miljø	Måleperiode 1
Produktionsmiljøet	99,9 %
Præproduktionsmiljøet	95,0 %
Eksternt Testmiljø	98,0 %

14 Systemets svartider

[Punkt 14 med underpunkter udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbe- hold overfor.]

14.1 Generelt om svartider

Leverandøren skal i Produktionsmiljøet foretage svartidsmålinger for funktionaliteten i Syste- met, som den anvendes af Brugere, Anvendere og Anvendersystemer via grænseflader til

Systemet og som den i øvrigt udføres af Systemet automatisk.

Svartidsmålingerne skal redegøre for, om der er væsentlige udsving i svartiderne for funktio- nalitet i Systemet. Formålet med Leverandørens svartidsmålinger er at måle og dokumen-

tere, at Leverandøren overholder Servicemål for svartider, samt redegøre for brugeroplevel- sen og identificere, hvor eventuelle lange svartider opstår ved eksekveringen af funktionalitet i Systemet, eller hvor eventuelle lange svartider opstår ved udførslen af automatiserede funk- tioner i Systemet.

Leverandøren har ansvaret for at sikre, at krav og Servicemål til alle svartider overholdes.

Leverandøren skal opsætte Monitorering med alarmer, der muliggør hurtig håndtering af Inci- dents, som beskrevet i punkt 14.3.5 og 0.

Leverandøren skal til svartidsmålingerne anvende en logning, der er passende detaljeret, så- ledes at dokumentationskrav kan imødekommes, herunder at hver måling skal registrere

starttidspunkt, sluttidspunkt, navnet på funktionen og kategori (jf. punkt 14.3.2 og punkt 0).

Der gælder Servicemål for svartider for hele funktionaliteten i Systemet. I forhold til måling og opgørelse af svartider er funktionaliteten grupperet, som følger:

• Funktionalitet udstillet via Systemets brugergrænseflader, jf. punkt 14.3.

• Funktionalitet udstillet via Systemets Eksterne Snitflader, jf. punkt 0.

Der gælder forskellige metoder for svartidsmåling og -opgørelse til følgende anvendelser:

• Initiering af Incident Management proces (baseres på stikprøvemålinger), jf. punkt

14.3.5 og 0

• Beregning af tidsrum med driftsforstyrrelser pga. lange svartider (baseres på stikprø- vemålinger), jf. punkt 14.3.6 og 0

• Svartidstest ifm. ændringer på Systemet, Prøver mm. (baseres på kontrolmåling), jf. punkt 14.4.

14.2 Modregning af svartid udenfor Systemet

Såfremt der er svartider fra Integrationer til andre systemer og retur modregnes denne del (’Integrationers Svartid’) i den samlede målte svartid, men Leverandøren skal dokumentere tiden for Integrationers Svartid. Den samlede målte svartid udgør dermed den brugerople-

vede svartid som rapporteres jf. bilag 7.2.G. Er Leverandøren ikke i stand til at dokumentere tiden for Integrationers Svartid, lægges den samlede målte svartid til grund inklusive tiden for Integrationers Svartid, og Leverandøren er således ansvarlig for at sikre, at den samlede

målte svartid overholder Servicemålene angivet i punkt 14.3.4 og punkt 0.

Leverandøren skal sikre, at svartiden fra Integrationer til Anvendersystemer måles og opgø-

res separat, således at henholdsvis Systemets svartid, Integrationers Svartid og den samlede svartid for hvert målepunkt kan dokumenteres som en del af driftsdokumentationen. Leveran- døren skal fremlægge denne Dokumentation som bilag til driftsrapporten.

Såfremt svartiderne fra Integration med et Anvendersystem ikke opfylder aftalte svartider med den pågældende Anvendersystemleverandør, skal Leverandøren orientere KOMBIT herom og via Incident Management processen, jf. punkt 1, rejse sag over for Anvendersy- stemleverandøren med henblik på at få afhjulpet forholdet.

For alle svartider gælder, at forsinkelser i Systemets svartider grundet forhold, som Leveran- døren dokumenterbart ikke er ansvarlig for, fratrækkes ved beregning af svartider. Sådanne forhold kan eksempelvis være fejl i andre systemer, som Leverandøren ikke er ansvarlig for, nedetid på forbindelsen til de offentlige registre, hvor der foretages opslag og berigtigelser mv. Leverandøren har bevisbyrden for, at en forsinkelse skyldes et af de nævnte forhold,

samt pligt til at kunne dokumentere den andel af svartiderne, der skal fratrækkes svartiderne pga. samme forhold.

Leverandøren skal udarbejde detaljeret redegørelse for svartidsmålingerne fremfor kun at op- gøre gennemsnitsværdier af målingerne ift. de opsatte Servicemål.

14.3 Svartider for transaktioner i brugergrænsefladen

14.3.1 Transaktioner og transaktioners svartider

Systemets funktionalitet udstilles til og anvendes af Brugere via brugergrænseflader, således at Brugerne via brugergrænsefladen sender forespørgsler til Systemet, der efter endt be-

handling sender et svar og opdaterer brugergrænsefladen.

Aktiviteten, som finder sted fra Brugeren sender forespørgslen, og til brugergrænsefladen er opdateret, udgør en transaktion.

Der kan således gennemføres mange forskellige transaktioner fx en søgning eller opdatering af en formular.

Ved svartiden for en transaktion i Systemets brugergrænseflade forstås tidsintervallet fra

Xxxxxxxx sender sin kommando, til resultatet er synligt for Xxxxxxxx, brugergrænsefladen er fuldt opdateret, og Xxxxxxxx har mulighed for afgivelse af en ny kommando.

Ved kommando forstås den meddelelse, der sendes til Systemet, når Enter/Return-tasten, en funktionstast eller tilsvarende tast/ikon aktiveres. Svartiderne måles således i forhold til bru- gergrænsefladen i Systemet.

14.3.2 Kategorisering af transaktioner i brugergrænsefladen

Afhængig af transaktionens kompleksitet inddeles hver transaktion i brugergrænsefladen i en af følgende 3 kategorier: Simpel, Middel eller Kompleks. Til hver kategori hører et sæt Ser-

vicemål for svartider, jf. punkt 14.3.4.

For hver transaktion i Systemet skal Leverandøren i Systemdokumentationen beskrive trans- aktionens kompleksitet og den deraf afledte kategori, som Simpel, Middel eller Kompleks.

Såfremt en transaktions kompleksitet ikke er tilstrækkeligt dokumenteret i Systemdokumenta- tionen, eller hvis den angivne kategori ikke godkendes af KOMBIT, vil KOMBIT angive kate- gorien baseret på et konkret skøn af kompleksiteten ud fra eksemplerne angivet i punkt

14.3.4.

14.3.3 Måling af svartider i brugergrænsefladen

For hver kategori af transaktionskompleksitet (jf. punkt 14.3.2) aftales et antal ”Målepunkter” (op til 5 Målepunkter pr. kategori), som tilsammen udgør et repræsentativt billede af Systemets samlede funktionalitet indenfor denne kategori. Hvorvidt et Målepunkt er repræsentativt eller ej, skal kunne verificeres ved efterfølgende brug af data fra relevante logs.

For hver kategori af transaktionskompleksitet skal Leverandøren indenfor måleperioderne (jf. punkt 2.3) med maksimalt 5 minutters interval udføre stikprøvemålinger af svartider i Syste- mets brugergrænseflader, dvs. at der mindst hvert 5. minut foretages stikprøvemålinger på

de aftalte målepunkter for de tre kategorier samtidigt. En fuldstændig opgørelse over stikprø- vemålingerne rapporteres på månedlig basis og vedlægges driftsrapporteringen.

De stikprøvemålinger, der foretages samtidigt for hver kategori på de aftalte Målepunkter, be- tegnes ”Stikprøvepakken” og anvendes ved beregning af tid, der fragår i Tilgængelig Driftstid, jf. punkt 14.3.6. En Stikprøvepakke kan således indeholde op til 9 samtidige stikprøvemålin- ger (op til tre Målepunkter pr. kategori (Simpel, Middel og Kompleks)).

Stikprøver skal være repræsentative i forhold til den reelle brug af Systemet, og målingen skal ske fra en klient-PC uden for Driftsmiljøet, eller gennem en applikation, der kan udføre

simulering af samme. Specifikationerne for denne klient-PC samt udformning af Målepunkter afklares mellem Parterne, idet Leverandøren skal dokumentere, at stikprøverne er repræsen- tative samt sikrer aftestning af alle områder af Systemet. Stikprøvemålingerne skal senest

være implementeret ved Overtagelsesprøven.

KOMBIT kan for egen regning bede en uvildig tredjepart med ekspertise indenfor performan- cemålinger om at gennemføre et review af Målepunkternes indhold for at sikre, at målingerne dækker Systemets arkitektur tilstrækkeligt. Leverandøren skal deltage uden beregning i af-

klaringsmøder med den udpegede tredjepart med det formål at sikre tredjepartens forståelse

for Systemets arkitektur og Målepunkternes udformning. Såfremt tredjeparten fremlægger an- befalinger til ændringer af Målepunkternes udformning, skal Leverandøren implementere

disse, såfremt KOMBIT ønsker dette.

Udover stikprøvemålinger skal Leverandøren anvende en passende detail-logning af svarti- der for samtlige transaktioner på Systemet. Detail-logs kan anvendes af Leverandøren til af- klaring i tilfælde af eksempelvis Incidents eller ved udfald af stikprøvemålinger, jf. punkt

14.3.6. Disse logs skal fremsendes til KOMBIT som en del af den månedlige driftsrapporte- ring. Detail-logs skal leveres i et format, der er læsbart på en almindelig kontor-PC.

14.3.4 Servicemål for svartider i brugergrænsefladen

Der er to niveauer af Servicemål for svartider, som skal overholdes; ønskede svartider og

maksimale svartider. For de ønskede svartider (”Ønskede Svartider”) er fastsat et Servicemål om, at 98 % af alle stikprøvemålinger skal overholde de Ønskede Svartider, mens Service-

målet for de maksimale svartider (”Maksimale Svartider”) er, at 99,9% af alle stikprøvemålin- ger skal overholde de Maksimale Svartider. Disse fraktil-niveauer anvendes som beskrevet i punkt 14.3.6, hvor de omregnes til et antal acceptable stikprøveoverskridelser, og ved Kon-

trolmålinger, jf. punkt 14.4.

Tabel 13 nedenfor angiver de Ønskede Svartider og Maksimale Svartider for hver kategori af transaktionstyperne samt eksempler på transaktioner i hver kategori. Inddeling i transaktions vil blive startet op som aktivitet i Afklaringsfasen og skal være afsluttet inden Overtagelses- prøven.

Ønskede og Maksimale Svartider for hver kategori af transaktion i Systemet
Transaktionens kategori	Ønskede Svartider (sekunder)	Maksimale Svartider (sekunder)	Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1
Type 1	1	2	Forbindelse til dataafhentningspunkt (fx SFTP server)
Type 2	2	3	Login i Servicedesk system
Type 3	4	6	Start afhentning af Datapakker

Tabel 13: Ønskede og Maksimale Svartider for hver kategori af transaktionskategori i Systemet

14.3.5 Incident-oprettelse ved lange svartider i Systemets brugergrænseflade

Dette afsnit beskriver, hvornår der skal oprettes en Incident på grund af lange svartider i Sy- stemets brugergrænseflade.

I det tilfælde, at en enkelt stikprøvemåling viser, at niveauet for Ønskede Svartider eller Mak- simale Svartider overstiges, skal der ikke nødvendigvis oprettes en Incident, idet følgende

gælder:

Der skal oprettes en Incident med prioritet A, såfremt Maksimale Svartider overskrides flere gange i en 60 minutters periode.

Der skal oprettes en Incident med prioritet B, såfremt et af følgende forhold opfyldes:

• to eller flere stikprøvemålinger, udtaget inden for en vilkårlig 60 minutters periode i måleperioden, viser svartider, der overstiger niveauet for Ønskede Svartider (uanset variation i Målepunkter eller kategori for målingerne)

• hvis tiden mellem to stikprøvemålinger på samme Målepunkt overskrider 14 minutter

Incidents, der oprettes jf. ovenstående, skal håndteres som enhver anden prioritet A eller B

Incident, herunder med overholdelse af samtlige Servicemål, jf. punkt 1, samt Problem hånd- tering, afledte RCA mm.

Eksempel:

En stikprøvemåling af svartiden for en Type 1 transaktion kl 13:04 overstiger den Øn-

skede Svartid på 1 sekund, og en stikprøvemåling kl 13.19 af en Type 2 transaktion viser overskridelse af den Maksimale Svartid på 3 sekunder. Der skal oprettes en Incident

med prioritet B, da niveauet for Ønskede Svartider er brudt to gange indenfor 60 minut- ter.

Udover ovennævnte tilfælde vil Incidents vedrørende oplevede svartidsproblemer også

kunne oprettes ved henvendelser fra Brugere, Anvendersystemleverandører og andre Inte-

ressenter til Leverandørens Service Desk. Disse Incidents håndteres fuldt som et Incident, jf. punkt 1, og ikke med de undtagelser beskrevet under dette punkt 14.3.5.

14.3.6 Beregning af tidsrum med driftsforstyrrelser pga. lange svartider i Systemets bru- gergrænseflade

Manglende opfyldelse af Ønskede Svartider eller Maksimale Svartider, jf. punkt 14.3.4, med- fører en reduktion af den Tilgængelige Driftstid for Applikationsdrift, som beregnes i punkt

13.1.2. Da reduktionen påvirker driftseffektiviteten opgøres den på kalendermånedsbasis som følger:

• Overskridelse af Xxxxxxxx Xxxxxxx:

Tidsrum, hvor stikprøvemålinger, jf. punkt 14.3.3, måler en svartid, der er højere end den Maksimale Svartid, fratrækkes i Tilgængelig Driftstid på følgende måde:

For hver Stikprøvepakke, jf. punkt 14.3.3, hvor en eller flere stikprøvemålinger viser

overskridelse af Xxxxxxxx Xxxxxxx, skal der fratrækkes 5 minutter fra den Tilgængelige Driftstid. Dog vil de første 2 Stikprøvepakker med sådanne overskridelser i Måleperi- ode 1 (svarende til en omtrentlig omregning af Servicemålet om overholdelse af Mak- simale Svartider i 99,9 % af måleperioden, jf. punkt 14.3.4) anses for acceptable over- skridelser og dermed ikke skulle fratrækkes i den Tilgængelige Driftstid.

• Overskridelse af Ønskede Svartid:

Tidsrum, hvor stikprøvemålinger måler en svartid uden overskridelse af Xxxxxxxx

Svartid, men med overskridelse af Ønsket Svartid, fratrækkes i Tilgængelig Driftstid på følgende måde:

For hver Stikprøvepakke, hvor der ikke er overskridelse af Maksimal Svartid, men hvor en eller flere stikprøvemålinger viser overskridelse af Ønsket Svartid, skal fra- trækkes 5 minutter fra Tilgængelige Driftstid. Dog vil de første 40 Stikprøvepakker

med sådanne overskridelser i Måleperiode 1 (svarende til en omtrentlig omregning af Servicemålet om overholdelse af Ønskede Svartider i 98% af måleperioden, jf. punkt

14.3.4) anses for acceptable overskridelser og dermed ikke skulle fratrækkes i den Tilgængelige Driftstid.

• Udfald af stikprøvemålinger:

Tidsrum, hvor der er udfald i stikprøvemålinger, fratrækkes i Tilgængelig Driftstid på følgende måde:

Såfremt tiden mellem to stikprøvemålinger på samme Målepunkt overskrider 6 minut-

ter, skal tiden mellem stikprøvemålingerne fratrækkes den Tilgængelige Driftstid, med- mindre KOMBIT skriftligt godkender Leverandørens dokumentation for, at udfaldet er et enkeltstående tilfælde, som åbenlyst skyldes fejl uden for Systemet, og det i øvrigt eventuelt kan dokumenteres, at Systemet har fungeret tilfredsstillende på trods af

manglende stikprøver vha. detail-logs for samtlige svartider i Systemet.

Om ovenstående gælder, at såfremt der ved samtidige Stikprøvepakker måles for høje svarti- der i forhold til de fastsatte Servicemål på mere end en Stikprøvepakke, vil dette kun tælle

som 1 overskridelse i beregning af reduktion af den Tilgængelige Driftstid.

I tilfælde af, at der er sammenfald mellem tidsperioder med stikprøver, som måler overskri- delser af svartider eller ved stikprøveudfald i henhold til dette punkt, og tidsperioder med pri- oritet B eller A Incidents, vil disse overskridelser og udfald ikke indgå i beregningen i dette

punkt, idet der aldrig kan tælles dobbelt nedetid i samme tidsperiode.

Eksempel:

Parterne har aftalt følgende antal Målepunkter for transaktionskategorierne:

Type 1 har 2 Målepunkter, Type 2 har 3 Målepunkter og Type 3 har ligeledes 3 angivne Målepunkter.

Leverandøren foretager stikprøvemålinger på de 8 aftalte Målepunkter samtidigt. Disse 8 samtidige stikprøvemålinger udgør tilsammen en Stikprøvepakke, og Stikprøvepakken

eksekveres med maksimalt 5 minutters interval.

Ved opgørelse af svartidsmålinger i en kalendermåneds måleperiode viser det sig, at 6 Stikprøvepakker indeholder stikprøvemålinger med overskridelser, hvoraf mindst én

overskridelse er en overskridelse af Xxxxxxxx Xxxxxxx. 52 Stikprøvepakker indeholder

stikprøvemålinger, der ikke overskrider Xxxxxxxx Xxxxxxx, men alene viser en eller flere overskridelser af Ønsket Svartid.

Da antallet af Stikprøvepakker med overskridelser af Xxxxxxxx Xxxxxxx overstiger de 2

acceptable overskridelser, reduceres Tilgængelig Driftstid derfor med (6-2) * 5 minutter = 20 minutter.

Da antallet af Stikprøvepakker, der ikke overskrider Xxxxxxxx Xxxxxxx, men med overskri- delser af Ønsket Svartid, overstiger de 40 acceptable, reduceres Tilgængelig Driftstid

derfor med (52-40) * 5 minutter = 60 minutter.

Den samlede tid, som fragår i Tilgængelig Driftstid, udgør derfor (20+60 minutter) 80 mi- nutter.

14.4 Kontrolmåling af svartider

Leverandøren skal gennemføre en kontrolmåling (”Kontrolmåling”) af Systemets samlede

funktionalitet, herunder både transaktioner i brugergrænsefladen (jf. punkt 14.3) og Service- transaktioner (inkl. automatiserede funktioner, jf. punkt 0) i Produktionsmiljøet som kontrol,

når konkrete forhold, eks. ved indrapportering af Incidents, indikerer, at svartiderne aktuelt

ikke opfyldes, men hvor de løbende stikprøvemålinger ikke giver fejlende udslag. Kontrolmå- linger udføres i øvrigt også som en del af aftestningen ved udførelse af ændringer i Syste-

met, ved Prøver o. lign, som en indikator på, hvorvidt svartider umiddelbart har været påvir- ket af ændringen.

Kontrolmålingen består af mange prædefinerede forskellige kald til Systemet, der eksekveres samtidigt som et batchjob, således at svartiderne over et kortere interval, måles intensivt.

Kontrolmålingen skal være repræsentativ i forhold til den reelle brug af Systemet og derved reflektere både forbrugsmønster og mønster i anvendt funktionalitet. Kontrolmålingen skal indeholde en diversitet og detaljering, der sandsynliggør, at afvigende svartider i enhver af

Systemets transaktioner i brugergrænsefladen eller Servicetransaktioner vil kunne aflæses i Kontrolmålingens resultat. Kontrolmålingen baseres på de overfor definerede Målepunkter. Kontrolmålingens udformning afklares samtidig med og ifølge samme proces som angivet for afklaringen af Målepunkter (jf. punkt 14.3.3 og punkt 0).

Efter idriftsættelse af Systemet skal Leverandøren løbende foreslå forbedringer til Kontrolmå- lingen, så Kontrolmålingen fortsat opfylder beskrivelsen i dette punkt 14.4, eksempelvis ved ændringer i forbrugsmønstre eller ændring af funktionalitet. Såfremt KOMBIT accepterer im- plementeringen af de foreslåede forbedringer, skal Leverandøren implementere disse uden

beregning.

For hvert Målepunkt (jf. punkt 14.3.3 og punkt 0) skal der i Kontrolmålingen indgå mindst 50 på hinanden følgende målinger af svartiden. Summen af de målinger i Kontrolmålingen, der vedrører transaktioner i brugergrænsefladen (”Summen af Brugergrænseflade-målinger”), og summen af de målinger i Kontrolmålingen, der vedrører Servicetransaktioner inkl. automati- serede funktioner (”Summen af Servicetransaktions-målinger”), udgør tilsammen samtlige

målinger i Kontrolmålingen.

Kontrolmålingen skal måle to niveauer af svartider; Ønskede Svartider og Maksimale Svarti- der, jf. punkt 14.3.4 og punkt 0.

For at en Kontrolmåling ikke fejler, skal Kontrolmålingen overholde alle fire Servicemål, jf.

punkt 14.3.4 og 0, dvs. overholde 98% af Ønskede Svartider og 99,9% af Maksimale Svarti- der for alle målinger af transaktioner i brugergrænsefladen, samt overholde 98% af Ønskede Svartider og 99,9% af Maksimale Svartider for alle målinger af Servicetransaktioner inkl. au- tomatiserede funktioner.

Kontrolmålingers resultat opgøres umiddelbart efter eksekveringen og rapporteres straks til KOMBIT.

Eksemplet herunder angiver, hvordan Leverandørens opfyldelse af Servicemålene vurderes på baggrund af Kontrolmålingen ved at beregne andelen af målinger, der opfylder den fast- satte Xxxxxxxxx henholdsvis Ønskede Svartid.

Eksempel:

En Kontrolmåling indeholder 100 målinger af 50 gentagelser, dvs. 5.000 målinger to- talt. Summen af Brugergrænseflade-målinger udgør 2.000, hvoraf 2 målinger har

overskredet den Maksimale Svartid, og 25 målinger har overskredet den Ønskede Svartid. Summen af Servicetransaktions-målinger er 3.000, hvoraf 0 målinger har overskredet den Xxxxxxxxx Xxxxxxx, og 43 målinger har overskredet den Ønskede Svartid.

Opfyldelsen af Servicemål for transitioner i brugergrænsefladen:

Summen af Brugergrænseflade-målinger er 2.000. Opfyldelsesgraden for den Maksi- male Svartid er 99,9%, og opfyldelsesgraden for den Ønskede Svartid er 98,75 %.

Servicemålet for den Maksimale Svartid udgør 99,9 %, og Servicemålet for den Øn- skede Svartid udgør 98 %.

Opfyldelsen af Servicemål for Servicetransitioner:

Summen af Servicetransaktions-målinger er 3.000. Opfyldelsesgraden for den Mak- simale Svartid er 100%, og opfyldelsesgraden for den Ønskede Svartid er 98,57%. Servicemålet for den Maksimale Svartid udgør 99,9 %, og Servicemålet for den Øn- skede Svartid udgør 98 %.

Kontrolmålingen fejler ikke, idet alle fire Servicemål overholdes.

Hvis Servicemålene for Maksimale Svartider ikke overholdes i en Kontrolmåling, oprettes der en prioritet A Incident, og der foreligger en driftsforstyrrelse, som indgår ved opgørelsen af

driftseffektiviteten, jf. punkt 13.1.2.

Hvis Servicemålene for Ønskede Svartider ikke overholdes i en Kontrolmåling, oprettes der en prioritet B Incident, og der foreligger en driftsforstyrrelse, som indgår ved opgørelsen af driftseffektiviteten, jf. punkt 13.1.2.

En Incident, som oprettes på baggrund af en fejlende Kontrolmåling, har starttidspunkt fra

målingen er udført eller burde være udført, og indtil en tilsvarende Kontrolmåling er gennem- ført uden overskridelser af Servicemål.

KAPITEL III Service Transition

15 Introduktion til Service Transition

Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leveran- døren skal levere som Service Transition under Driftskontrakten.

Dette omfatter Ydelser og Servicemål indenfor følgende ydelsesområder:

• Opdatering af Systemet med nye Versioner i form af releasepakker under Release and Deployment Management, jf. punkt 18, og til gennemførelse som Changes via

Change Management, jf. punkt 16. Nye Versioner kan indeholde ny funktionalitet så- vel som fejlrettelser som følge af Incident Management og Problem Management.

• Gennemførelse af hastefejlrettelser og andre hasteændringer til Systemet og Driftsmil- jøet med Emergency Changes via Change Management, jf. punkt 16. Emergency

Changes kan være resultatet af behov for Omgåelse og afhjælpning under Incident Management eller Problem Management.

• Opdatering af Programmel i Systemet og/eller opdatering af Infrastrukturen med Pat- ches eller Emergency Patches via Patch Management, jf. punkt 18 og Change Mana- gement, jf. punkt 16. Emergency Patches kan f.eks. være resultat af, at en Underleve- randør publicerer en rettelse til Standardprogrammel i forbindelse med en sikkerheds- relateret Fejl.

• Test i forbindelse med opdatering af Systemet eller Infrastrukturen, jf. punkt 17.

• Planlægning af fremtidige nye Versioner, herunder både Major Version og Minor Ver- sion, til planmæssige opdateringer af Systemet, jf. punkt 18.6.

• Opbevaring af samt registrering af information om alle elementer for Systemet og In- frastrukturen og elementer i central database via Asset- og Configuration Manage- ment, jf. punkt 20.

• Vidensdeling med alle Interessenter i forbindelse med Service Transition via Know- ledge Management, jf. punkt 21.

16 Change Management

Ved Change Management forstås i dette bilag den del af Change Management processen i

relation til godkendelse og idriftsættelse af Changes til Systemet, herunder i forbindelse med implementering af ny funktionalitet leveret under Kontrakten, samt Changes til selve Produk- tionsmiljøet.

Ændringer til selve Systemets funktionalitet, der ikke sker som en del af Leverandørens ved- ligeholdelsespligter i henhold til Driftskontrakten, bestilles som ændringshåndtering i henhold til Kontrakten. Når sådanne ændringer er klar til levering, implementeres de i Systemet i

overensstemmelse med den aftale, der er indgået i medfør af Kontrakten, og under Change Management processen beskrevet under dette punkt 16.

Leverandøren skal med Change Management processen sikre, at alle ændringer, der skal fo- retages til Systemet samt ændringer til selve Produktionsmiljøet, håndteres som Changes ef- ter faste og veldefinerede rutiner med fokus på bl.a. risikominimering, kvalitetssikring og for- retningsmæssig relevans, som beskrevet under nærværende punkt. Dette gælder uanset, om den pågældende ændring sker på foranledning af Leverandøren, KOMBIT, Anvendersystem- leverandører eller Tredjepartsprogrammelleverandør.

Changes/ændringer bestilles som Change Management via en Request for Change (RfC), når denne er klar til at blive implementeret, herunder i forbindelse med Prøver, jf. Kontrak-

tens bilag 6. RfC’en oprettes i Leverandørens IT service management system og behandles herefter i Change Advisory Board, jf. bilag 7.2.G.

Leverandøren skal honorere KOMBITs rimelige ønsker til tidsplan for gennemførelse af

Changes med henblik på at understøtte effektiv driftsafvikling og planmæssig videreudvikling af Systemet.

Leverandørens Ydelser i forbindelse med Change Management er som følger:

• Initiere Change Management processen baseret på en modtaget RfC, uanset om RfC’en hidrører fra Leverandørens organisation eller KOMBITs organisation

• Prioritering og vurdering af den fremsendte RfC i forhold til gennemførelse, herunder risikovurdering, jf. punkt 16.2

• Dokumentation af alle Changes, jf. punkt 16.3

• Forberedelse til samt gennemførelse af RfC’ens behandling i Change Advisory Board, jf. bilag 7.2.G, i forbindelse med KOMBITs stillingtagen til godkendelse

• Forberedelse til samt gennemførelse af hastebehandling for Emergency Change

• Modtage og behandle RfC fra supportberettigede Brugere samt KOMBIT, Anvendersy- stemleverandører eller Tredjepartsprogrammelleverandører.

• Løbende orientering af indberetteren af RfC, om status, herunder i forbindelse med afvisning eller godkendelse i Change Advisory Board

• Orientering af Interessenter om kommende, udestående og afsluttede Changes. Dette omfatter kommunikation ved hjælp af mail og/eller en dertil indrettet hjemmeside

• Planlægning og gennemførelse af idriftsættelse af RfC

• Kvalitetssikring af gennemført RfC, herunder tilbagerulning til tilstanden før gennemfø- relsen i tilfælde af mislykket gennemførelse

• Gennemføre Standard Changes i overensstemmelse med Parternes aftaler herom

Leverandøren skal i sine prøveplaner, jf. bilag 6, sikre, at Change Management processen opfyldes.

I forbindelse med idriftsættelse af Changes i forhold til Integrationer eller implementering af Systemet hos Anvendere vil KOMBIT have muligheden for at kunne aftale udvidet åbningstid eller øget beredskab i en periode. Desuden kan der, ved mere komplekse testopgaver være behov for et fælles forløb mellem leverandørerne. Dette aftales og planlægges, når behovet opstår, og Leverandørens dokumenterede merudgifter til dette afregnes efter forbrug i over- ensstemmelse med Driftskontraktens bestemmelser om udførelse af timebaserede ressourcer. Løsningen og ydelserne beskrives i RfC’en og er dermed ikke en del af det månedlige vederlag i bilag 7.2.B.

16.1 Servicemål for Change Management

Servicemålene vedrørende Change Management er, at for alle planlagte Changes skal mindst 95 % være succesfuldt gennemført i kalendermåneden.

En Change er succesfuldt gennemført, når Changen er gennemført i sin helhed på det plan- lagte gennemførelsestidspunkt, Systemet er opdateret i overensstemmelse med formålet

med Changen, og Systemet i øvrigt opfylder Kontraktens krav, herunder til Servicemål.

16.2 Risikovurdering af RfC

I forbindelse med vurderingen af en RfC skal Leverandøren altid sikre, at der gennemføres en behørig risikovurdering, som fremsendes sammen med RfC til KOMBIT. Risikovurderin- gen skal omfatte stillingtagen til følgende:

• Hvor stor en indsats kræves for at gennemføre RfC’en, herunder behov for forbere- delse, planlægning og involvering af flere personer?

• Hvor kompleks er RfC’en, herunder hvor stor en del af Systemet og Infrastrukturen, der berøres?

• I hvor stort et omfang de ændringer, der er specificeret i RfC’en, kan rulles tilbage i

tilfælde af Fejl under gennemførelsen. Indsats og sandsynlighed for succes med tilba- gerulningen skal indgå i vurderingen.

16.3 Dokumentation af RfC

Leverandøren skal sikre, at RfC’en dokumenteres i Leverandørens IT service management system. Medmindre andet er aftalt skal dokumentationen omfatte følgende:

• En beskrivelse af Changens formål

• En beskrivelse af Changens driftsmæssige konsekvenser, mens Changen gennemfø- res

• En detaljeret beskrivelse af, hvordan Changen gennemføres

• Start og sluttidspunkt for Changens gennemførelse

• En realistisk tidsplan med mulighed for evt. tilbagerulning

• En risikovurdering efter retningslinjer i punkt 16.2

• En kategorisering af Changen som Standard Change, eller lav-risiko, mellem-risiko eller høj-risiko Change baseret på risikovurderingen

• En tilbagerulningsplan, der beskriver, hvordan en helt eller delvist gennemført Change kan omgøres, så Systemet føres tilbage til tilstanden umiddelbart før Changens påbe- gyndelse

• Eventuelle konsekvenser for Dokumentation, herunder installationsvejledninger, drifts- vejledninger mv.

• Eventuelle konsekvenser for Leverandørens Ydelser og overholdelse af Servicemål

• Eventuelle konsekvenser for supportsamarbejdet

17 Validation og test

Leverandøren skal sikre, at alle nye Versioner, jf. punkt 18, testes behørigt i overensstem- melse med Kontraktens bilag 6.

• Leverandøren skal sikre, at Internt Testmiljø samt Præproduktionsmiljøet i perioden Arbejdsdage kl. 08.00 til 16.00 samt øvrige tider, hvor der skal foregå test, er anven-

delige til testformål, herunder at eksempelvis programmel, testdata, konfiguration, fun- gerende Integrationer og brugeradgange er fungerende. Konstaterer Leverandøren, at miljøerne ikke er anvendelige, skal Leverandøren straks skriftligt orientere KOMBIT

herom.

• Incidents i testmiljøerne og Præproduktionsmiljøet, som forstyrrer gennemførelsen af tests, skal være løst jf. punkt 1, således at tests kan gennemføres som planlagt.

• Leverandøren skal kunne tage et snapshot af det Eksterne Testmiljø. Et snapshot in- deholder nødvendig information om Programmel, Konfigurationsmateriale og data i

Systemet samt Driftsmiljøet, således at miljøet kan genetableres på et senere tids- punkt.

• Leverandøren skal underrette KOMBIT inden 14 Arbejdsdage, såfremt et snapshot bli- ver forældet og ikke kan benyttes som følge af Changes i Systemet eller Driftsmiljøet.

• Leverandøren skal kunne udføre et snapshot senest 3 Arbejdsdage efter forespørgs- len er modtaget. På KOMBITs foranledning skal Leverandøren kunne genetablere

Eksternt Testmiljø i Driftsmiljøet til et givent snapshot, når fx Anvendersystemets brug af testmiljøet har gjort det nødvendigt at reetablere data i et givent testmiljø.

• Leverandøren skal varsle Anvendersystemleverandører før genetableringen. Efter genetablering skal der udføres og bestås en installationstest, jf. bilag 6.

• Genetablering skal kunne udføres senest 3 Arbejdsdage efter modtagelsen af fore- spørgslen.

På KOMBITS foranledning skal Leverandøren udføre op til 15 fyldestgørende snapshot og genetableringer om året.

Leverandøren leverer følgende Ydelser til validering og test i relevant og nødvendigt omfang:

• Test af alle Patches og Emergency Patches i forbindelse med opdatering af Program- mel/programmel i Systemet og Driftsmiljøet, jf. punkt 18.

• Test af alle nye Versioner af Tredjepartsprogrammel i overensstemmelse med be- stemmelserne i bilag 6.

• Sikring af, at der før installeringen i Driftsmiljøet gennemføres tilstrækkelige tests i

omfang, art og dækning til, at det verificeres, at fejlrettelserne mv. er gennemført med succes. Leverandøren skal således med testen verificere, at fejlrettelserne mv. løser og/eller afhjælper de under Incident Management eller Problem Management identifi- cerede Incidents, Problems og/eller Fejl, samt at der med fejlrettelserne mv. ikke op- står nye Incidents eller Problems, herunder funktionelle Fejl eller utilstrækkelig perfor- mance. Leverandøren skal således sikre, at Systemets opdatering med fejlrettelserne mv. herved kvalitetssikres i tilstrækkeligt omfang til at kunne levere fejlfri og stabil

drift under overholdelse af alle Servicemål. Leverandøren skal i forbindelse med te-

sten gennemføre funktionel afprøvning på Internt Testmiljø, integrationsafprøvning på Præproduktionsmiljøet samt performance- og load afprøvning i Præproduktionsmiljøet i relevant omfang, jf. også bilag 6.

• Dokumentation af gennemførte tests samt resultatet heraf i forbindelse med alle fejl- rettelser, Changes og Patches til Systemet og Driftsmiljøet. Dokumentationen leveres som en del Systemdokumentation og driftsdokumentationen.

18 Release and Deployment Management

Leverandøren skal vedligeholde Driftsmiljøet og Systemet. Krav til Leverandørens vedligehol- delse af Systemet og Infrastrukturen fremgår af Driftskontraktens punkt 6 samt nærværende punkt.

Leverandørens Ydelser til Release and Deployment Management processen omfatter både Systemet, herunder Tredjepartsprogrammel og Driftsmiljøet.

Leverandøren leverer følgende Ydelser til Release and Deployment Management, medmin- dre andet aftales med KOMBIT:

• Vedligeholdelse af Systemet med nye Versioner af Programmel fra Leverandøren, jf. punkt 18.1

• Vedligeholdelse af Driftsmiljøet med nye versioner af programmel, jf. punkt 18.1.

• Vedligeholdelse af Systemet med nye Versioner af Tredjepartsprogrammel, jf. punkt 18.2

• Vedligeholdelse af Integrationer, jf. punkt 18.3

• Vedligeholdelse af data, jf. punkt 18.4

• Planlægning af releases og sikring af sporbarhed i indholdet af releases til releases enkeltdele, herunder planlægning af nye Versioner, jf. punkt 18.6

• Sikring af koordination, involvering og styring af de relevante Interessenter, herunder Tredjepartsprogrammelleverandører, Anvendersystemleverandører og Brugere

• Stille tilstrækkelig og nødvendige ressourcer til rådighed til deployment, verifikation, fejlsøgning, fejlrettelse samt roll-back

• Sikring af sammenhængende test af det samlede release, herunder integrationstest og en samlet performance- og loadtest, jf. bilag 6

• Sikring af behørig dokumentation af leverancer, jf. bilag 4

• Sikring af tilstedeværelsen af rollback planer for et release

Vedligeholdelse af Systemet og Infrastrukturen skal udføres af kvalificeret personale, der har kendskab til Systemet og Infrastrukturen.

Det er Leverandørens ansvar umiddelbart efter gennemførelsen af en Change at sikre behø- rig test samt dokumentere dette overfor KOMBIT, herunder i forbindelse med en eventuel au- dit/kontrol.

Leverandøren skal gøre det muligt for KOMBIT at deltage som observatør ved gennemførel- sen af Changes samt deltage aktivt eller som observatør i forbindelse med Leverandørens

test af Changes efter gennemførelsen.

Vedligeholdelsen skal finde sted i de aftalte servicevinduer, jf. punkt 18.5.

18.1 Vedligeholdelse af System og Driftsmiljøe med ny Versi- onr

Leverandørens vedligeholdelse af Systemet og Driftsmiljøet omfatter at levere nye Versioner af Programmel til Systemet og nye versioner af programmel til Driftsmiljøet, herunder det

som Leverandøren tidligere har leveret under Kontrakten. Leveringen af nye Versioner af Sy- stemet skal ske i overensstemmelse med Driftskontraktens punkt 6.7.

Leverandøren skal proaktivt tage initiativ til, at Tredjepartsprogrammel tilpasses efter behov af Tredjepartsprogrammelleverandøren, så det pågældende Tredjepartsprogrammel kan fun- gere med de leverede nye Versioner af Programmel til Systemet og/eller nye versioner af

programmel til Driftsmiljøet. Leverandøren skal i den forbindelse bl.a. koordinere og styre eventuelle nødvendige opdateringer fra Tredjepartsprogrammelleverandører, såfremt dette

skulle vise sig påkrævet i forbindelse med ny version af eksempelvis databaseserver, appli- kationsserver eller lign. Det er KOMBITs ansvar at sikre det nødvendige aftaleforhold med Tredjepartsprogrammelleverandøren. Leverandøren skal efter behov sikre KOMBITs inddra-

gelse i koordineringen med Tredjepartsprogrammelleverandører. I tilfælde af, at Tredjeparts- programmelleverandøren ikke imødekommer anmodninger fra Leverandøren om at tilpasse Tredjepartsprogrammel, skal Leverandøren eskalere dette til KOMBIT.

Leverandøren leverer nye Versioner af Standardprogrammel til Systemet så snart og i det omfang, at sådant Programmel er frigivet til distribution i Danmark, og i øvrigt besluttet i CAB, jf. bilag 7.2.G.

En version af en Integration eller Systemets Eksterne Snitflader kan kun nedtages eller æn- dres efter forudgående skriftlig aftale med KOMBIT.

Leverandøren leverer nye versioner af programmel til Driftsmiljøet, når det er relevant for Le- verandøren eller krævet for at kunne driftsafvikle nye Versioner af Programmel til Systemet, og i øvrigt besluttet i CAB, jf. bilag 7.2.G.

Leverandøren orienterer uden ugrundet ophold KOMBIT samt øvrige Anvendere om nye Ver- sioner/versioner, herunder om væsentlige ændringer i forhold til tidligere Versioner/versioner, når sådanne foreligger.

Leverandøren skal i forbindelse med nye Versioner/versioner orientere KOMBIT om konse-

kvenserne ved at installere en ny Version/version, og ved ikke at installere en ny Version/ver- sion, herunder Leverandørens overholdelse af Systemets Servicemål.

Hvis KOMBIT ønsker den nye Version/version installeret, forestår Leverandøren sådan in- stallation i Systemet samt Driftsmiljøet.

Leverandøren skal sikre, at nye Versioner af Programmel til Systemet og nye versioner af programmel til Driftsmiljøet testes behørigt og i overensstemmelse med bestemmelserne herom, jf. bilag 6.

Leverandøren skal herefter opdatere Systemet i Internt Testmiljø, Præproduktionsmiljøet, Eksternt Testmiljø og Produktionsmiljøet med de leverede nye Versioner af Programmel.

Dette omfatter at installere de nye Versioner samt efter behov foretage koordinerede ændrin- ger i konfigurationen af Systemet. Dette skal følge Change Management processen, jf. punkt 16.

[Resten af punkt 18.1 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold over- for].

Programmel samt programmel i Driftsmiljøet skal maksimalt være 1 Major Version bagud i forhold til senest frigivne Major Version, såfremt KOMBIT anmoder herom.

Opfyldelsen af Driftskontraktens krav og Servicemål forudsætter, at Programmel maksimalt

er to Major Versioner bagud i forhold til senest frigivne Major Version. Uanset førnævnte skal krav og Servicemål dog opfyldes, så længe den af KOMBIT benyttede Version er modtaget af KOMBIT inden for de seneste 12 måneder.

Det er Leverandørens ansvar at sikre, at ovenstående krav til versionering opfyldes.

18.2 Vedligeholdelse af Systemet med 3.partsprogrammel

Leverandørens vedligeholdelse af Systemet omfatter at opdatere Systemet med nye Versio- ner af Tredjepartsprogrammel, der tidligere er idriftsat i Systemet. Dette skal ske i overens- stemmelse med Driftskontraktens punkt 6 samt den vedligeholdelsesaftale, der er indgået mellem KOMBIT og Tredjepartsprogrammelleverandør.

Leverandøren skal sikre, at nye Versioner af Tredjepartsprogrammel testes behørigt og i overensstemmelse med bestemmelserne under punkt 17.

Leverandøren skal herefter opdatere Systemet i Internt Testmiljø, Produktionsmiljøet, Præ- produktionsmiljøet og Eksternt Testmiljø med de leverede nye Versioner af Tredjepartspro-

grammel. Dette omfatter at installere de nye Versioner samt efter behov foretage ændringer i konfigurationen af Systemet. Dette skal følge Change Management processen, jf. punkt 16.

18.3 Vedligeholdelse af Integrationer

Leverandøren har ansvar for at tage initiativ til at planlægge, koordinere og gennemføre op- dateringer af Integrationer, der nødvendiggøres af ændringer i Systemet, en Integration eller andre forhold. Hvis eksempelvis en Ekstern Snitflade til et Anvendersystem, som anvendes af en Integration, ændres, skal Integrationen tilpasses i nødvendigt omfang og den nye Ver- sion af Integrationen idriftsættes.

Leverandøren skal sikre, at KOMBIT orienteres om behovet for, at der leveres ny Version af en Integration. KOMBIT skal på den baggrund kunne bestille ny Version af Integrationen som videreudvikling hos Leverandøren eller Tredjepartsprogrammel fra Tredjepartsprogrammelle- verandør.

Såfremt en ny Version af Systemet eller en ny Version af en Integration, medfører ændringer til en eller flere af Systemets Eksterne Snitflader til et eller flere Anvendersystemer, skal Le- verandøren sikre, at Anvendere får et passende varsel på mindst 180 dage og en passende tidsperiode til at opdatere Anvendersystemerne i overensstemmelse med Systemets Eks-

terne Snitflader.

En Version af en Integration eller Systemets Eksterne Snitflader kan kun nedtages eller æn- dres efter forudgående skriftlig aftale med KOMBIT.

Leverandøren skal levere følgende Ydelser:

• Holde sig løbende orienteret om Anvendersystemleverandørers planer for kommende nye versioner af de Eksterne Snitflader, der integreres til fra Systemet, herunder være kontaktperson for KOMBIT i forhold til leverandørerne af Anvendersystemer.

• Tage initiativ til, planlægge, risikovurdere, konsekvensvurdere og prioritere potentiel videreudvikling af de Integrationer i Systemet, der påvirkes af nye versioner af Eks- terne Snitflader til Anvendersystemer.

• Uden ugrundet ophold orientere KOMBIT om behovet for bestilling af nye Versioner af Integrationer, hvor behovet skyldes opdaterede versioner af Anvendersystemernes

eksterne snitflader, der anvendes fra Integrationerne. Leverandørens orientering af

KOMBIT om behovet for nye Versioner skal som minimum omfatte konsekvensvurde-

ring, risikovurdering samt en anbefalet prioritering i tilstrækkeligt omfang til, at KOM-

BIT kan træffe beslutning om bestilling af videreudvikling af Integrationer på oplyst grundlag.

• Planlægge tidsperiode for afvikling af tidligere Versioner af Eksterne Snitflader, der publiceres af Systemet til anvendelse af Anvendelsessystemer.

• Orientere KOMBIT samt Interessenter, der anvender den pågældende Eksterne Snit- flade til Systemet, via mail og den dertil indrettede hjemmeside om tidsplan for udfas- ning af tidligere versioner som aftalt med KOMBIT. Leverandøren skal foretage denne orientering uden ugrundet ophold.

• Driftsafvikle tidligere Versioner af Eksterne Snitflader til Systemet, sideløbende med seneste Version indtil tidspunkt for planlagt udfasning.

• Leverandøren skal indhente KOMBITs skriftlige godkendelse, før udfasning af tidligere Version af den Eksterne Snitflade til Systemet kan gennemføres.

18.4 Sletning af data

Anvenderne skal rette henvendelse til KOMBIT, hvis de ønsker data, som de er (data)ansvar- lige for, slettet i Systemet og Driftsmiljøet, medmindre andet aftales mellem Parterne.

KOMBIT fremsætter herefter skriftligt de(n) pågældende Anvender(e)s vedligeholdelsesan- modning til Leverandøren, som herefter a) fastlægger, hvilke data der skal slettes for at imø- dekomme de(n) pågældende Anvender(e)s anmodning, og b) gennemfører sletning af data. Er KOMBITs anmodning ikke fremsat skriftligt, må Leverandøren ikke efterkomme anmodnin- gen.

KOMBIT skal i nødvendigt omfang bistå Leverandøren med at fastslå, hvilke data der skal slettes.

18.4.1 Servicemål for sletning af data

Sletning af data er en del af vedligeholdelsen af Systemet og Driftsmiljøet og skal finde sted i det første servicevindue efter anmodning herom er fremsendt fra KOMBIT.

Leverandøren skal senest 3 Arbejdsdage inden sletning af data skriftligt orientere KOMBIT om den planlagte sletning.

18.5 Servicevinduer til vedligeholdelse

[Punkt 18.5 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].

Vedligeholdelsesarbejdet i Produktionsmiljøet skal finde sted i de servicevinduer, der fremgår af nedenstående. Der anvendes i denne forbindelse følgende begreber med den anførte be-

tydning:

- Servicevindue betyder den periode, hvor vedligeholdelsen må finde sted.

- Varighed betyder den varighed, som vedligeholdelsen må have i det pågældende ser- vicevindue.

- Varsling betyder det skriftlige varsel, som Leverandøren skal give KOMBIT forud for et planlagt servicevindue, idet et servicevindue ikke må gennemføres uden et sådant var- sel.

Vedligeholdelsesarbejde skal ske i de servicevinduer, der fremgår af Tabel 14:

Mindre opdateringer:

Servicevindue: 1 gang om ugen i tidsrummet fredag kl.

01.00- 02.00 CET

Varighed: 1 time

Varsling: 1 uge

Større og kritiske opdateringer:

Servicevindue: Op til 1 gang pr. måned i tidsrummet lørdag kl. 01.00 til lørdag kl. 05.00 CET

Varighed: 4 timer

Varsling: 1 måned

Omlægning af miljøer, arkitektur og services:

Servicevindue: 1 gang pr. kvartal i tidsrummet lørdag kl.

00.00 til lørdag kl. 08.00 CET

Varighed: 8 timer

Varsling: 2 måneder

Tabel 14: Servicevinduer

Leverandøren kan ikke benytte sig af de fastlægte servicevinduer 3 Arbejdsdage før og 5 Ar- bejdsdage efter en fuld Dataindlæsning, medmindre dette aftales skriftligt med KOMBIT.

Vedligeholdelsesarbejdet skal planlægges og udføres, så det er til mindst mulig gene for Bru- gerne. Såfremt vedligeholdelsesarbejdet nødvendiggør hel eller delvis nedetid af Systemet,

skal Leverandøren indhente KOMBITs skriftlige tilladelse hertil forud for, at Systemet lukkes ned.

Nægter KOMBIT i et aftalt servicevindue at tillade en hel eller delvis afbrydelse af Systemet efter Leverandørens anmodning derom, er dette at betragte som en af KOMBIT anmodet ud- skydelse af det pågældende vedligeholdelsesarbejde. Såfremt den udskudte vedligeholdelse i sådanne tilfælde dokumenterbart er årsag til en forringelse af opfyldelsen af Servicemålene specificeret i nærværende bilag, eller i øvrigt aftalte krav, er Leverandøren ikke ansvarlig

herfor i den periode, som vedligeholdelsen udskydes. Leverandøren skal forudgående, skrift- ligt meddele KOMBIT, såfremt Leverandøren mener, at en sådan ansvarsfritagelse finder an- vendelse.

Leverandøren og KOMBIT kan i særlige tilfælde aftale ekstraordinære servicevinduer. Dette skal skriftligt godkendes af KOMBIT.

18.6 Plan for nye Versioner

Leverandøren udarbejder i overensstemmelse med Driftskontraktens punkt 6.7 en plan med 12 måneders horisont for idriftsættelse af nye Versioner af Systemet. Planen skal opdateres hver kalendermåned.

19 Patch Management

Patch Management processen gør det muligt for Leverandøren at levere opdateringer af Programmel i Systemet og programmel i Driftsmiljøet.

Formålet med Patch er at rette fejl, samt afbøde sikkerhedsbrister og sikkerhedsrisici.

En Patch er en afgrænset opdatering af Programmel i Systemet, programmel i Infrastrukturen (f.eks. operativsystemer, switches, firewalls m.v.), firmware til udstyr og / eller Tredjepartsprogrammel.

Patches deles op i følgende fire kategorier:

Niveau	Definition
Kritisk	Sårbarheder, hvis udnyttelse kan medføre kompromittering af fortrolighed, integri- tet eller tilgængeligheden af brugerdata i forbindelse med eks. persondataloven, eller eksekvering af kode uden advarsler eller prompter
Vigtig	Sårbarheder hvis udnyttelse kan medføre kompromittering af fortrolighed, integri- tet eller tilgængeligheden af brugerdata, eller systemresurser
Moderat	Patches, der har til formål at sikre, at sårbarheder afbødes i betydelig grad, såle- des at der ikke kan skabes prioritet A eller B incidents.
Øvrige	Patches, der ikke dækkes af Moderat sikkerhedspatches

Tabel 15: Patch kategorier

Leverandøren skal levere følgende ydelser:

• Leverandøren skal opretholde og anvende sikkerhedsrettelser inden for rammerne af ydede tjenester og enhver infrastruktur, der anvendes til at levere denne service, som kunden kræver.

• Leverandøren skal sikre sig at leve fuldt op til de i Bilag 7.2 stk. 13.4 nævnte lovgivningsmæs- sige krav

• Leverandøren skal uden unødigt ophold informere KOMBITs Driftschef og Service Manager om identificerede sikkerhedsrettelser, der ikke kan anvendes i it-infrastrukturen.

• Leverandøren skal sikre, at gældende sikkerhedsrettelser, efter frigivelse, er testet og imple- menteret i henhold til nedenstående skema. Sikkerhedsrettelser kategoriseret som kritiske af softwareproducenten, skal anvendes uden unødig forsinkelse

• Leverandøren skal sikre og vedligeholde en Service Management Procedure, der inkluderer en Patch proces, og som indgår i Driftshåndbogen jf. Bilag 7.2.F

Service Management Proceduren skal blandt andet indeholde følgende:

• Patches risikoevalueres først hos Leverandøren, hvorefter udrulning foretages inden for de an- givne værdier.

• Sikkerhedspatches testes før installation, og det skal sikres, at servere efter opdatering fungerer korrekt

• Dokumentation, jf. bilag 4 og bilag 7.2.F, indeholdende overblik over installerede Patches samt publicerede, men endnu ikke installerede Patches.

• Det er Leverandørens ansvar løbende at holde sig opdateret om og fremskaffe nye Patches til standardprogrammel og programmel i driftsmiljøet samt installere disse via Change Manage- ment processen.

• Det er KOMBITs ansvar at sikre det nødvendige aftalegrundlag for, at tredjepartsprogrammel- leverandører orienterer Leverandøren om og leverer Patches til tredjepartsprogrammel.

• Installation af Patches skal følge Change Management processen, jf. punkt 16.

19.1 Servicemål for Patch Management

Leverandøren skal ved konstatering af en sikkerhedsmæssig brist eller risiko, som beskrevet i neden- stående tabel 19 under Kritiske Sikkerhedsmæssige Patches, uden ugrundet ophold og inden for 30 minutter kontakte KOMBITs Driftschef, primært på telefon, sekundært via SMS og mail, og informere om den sikkerhedsmæssige risiko og plan for løsning. Hvis der ikke kan opnås kontakt til KOMBITs

Driftschef, skal Leverandøren uden yderligere ophold udføre de nødvendige tiltag for at imødegå den sikkerhedsmæssige risiko.

Nedenstående tabel beskriver installationsfristen, gældende for Patch af systemet og infrastrukturkom- ponenter. Disse frister tilsidesætter ikke servicemål for Incident Management i tilfælde af driftsforstyr- relser.

Patch type

Installationsfrist

Servicemål for

opfyldelsesgrad (%)

Kritiske sikkerhedsmæssige Patches:

Eksempelvis: Sårbarheder, hvis udnyttelse kan medføre kompromittering af fortrolighed, integritet eller tilgænge- ligheden af brugerdata i forbindelse med eks. personda- taloven, eller eksekvering af kode uden advarsler eller prompter

Hurtigst muligt, dog senest efter 3

timer

100

Vigtige sikkerhedsmæssige Patches:

Eksempelvis: Sårbarheder hvis udnyttelse kan medføre kompromittering af fortrolighed, integritet eller tilgænge- ligheden af brugerdata, eller systemresurser

10 Arbejdsdage

100

Moderate Patches:

Eksempelvis: Patches, der har til formål at sikre, at sår- barheder afbødes i betydelig grad, således at der ikke kan skabes prioritet A eller B incidents.

20 Arbejdsdage

100

Øvrige Patches:

Eksempelvis: Patches. der ikke dækkes af moderate sikkerhedspatches

Efter aftale – dog højst 90 dage

100

Tabel 16: Servicemål for Patch Management

Installationsfristen beskriver den tid, der maksimalt må gå, før relevante Patches er installeret, og gæl- der fra det tidspunkt, hvor en Patch er frigivet.

Der er efter forudgående skriftlig aftale med KOMBIT mulighed for at nedgradere Patch typen, hvis Patch typen vurderes som mindre betydende. KOMBIT kan afvise et ønske fra Leverandøren om at nedgradere Patch typen.

Såfremt Leverandøren ikke er i stand til at opfylde installationsfristen for udrulning af en Kritisk Sikker- hedsmæssig Patch, skal hele forløbet behandles som en prioritet A incident, og Leverandøren skal i så fald introducere en omgåelse af Incident, som KOMBIT uden yderligere ophold skal orienteres om og godkende.

19.1.1 Manglende opfyldelse af servicemål

Såfremt Leverandøren ikke fjerner en sikkerhedsmæssig risiko inden for de under dette punkt 18.1 nævnte frister/Servicemål, skal forholdet anses og behandles som en kritisk sikkerhedsmæssig brist og dermed som en kritisk Incident /Prioritet A) og de Servicemål mv., der gælder herfor, jf. punkt 1 og 1.

19.1.2 Uenighed om kategorisering af risici og opfyldelse af Servicemål eller frister

Ved uenighed mellem Parterne om, hvorvidt en Patch er omfattet af de under punkt 19.1 omfattede Patches, og/eller hvorvidt en risiko er omfattet af punkt 19.1, og/eller hvorvidt et forhold generelt udgør en risiko, skal uenigheden løses i overensstemmelse med Driftskontraktens punkt 33.2.

Ved uenighed om, hvorvidt et Servicemål og/eller fristerne under dette punkt er opfyldt, afgøres tvisten i overensstemmelse med Driftskontraktens punkt 33.2.

20 Asset- og Configuration Management

Leverandøren skal sikre, at alle elementer, der indgår i Systemet og Driftsmiljøet, registreres behørigt, og at disse registreringer opbevares i en central database (Configuration Manage- ment Database). Dette skal bl.a. omfatte programkode, Dokumentation, programscripts, kon- figurationsfiler, licenser mv. Leverandøren skal sikre, at den centrale database er opdateret, samt at adgangen til registrerede elementer eller information kan foregå uafhængig af enkelt- personers tilgængelighed.

Leverandøren skal sikre, at processerne for Asset- og Configuration Management, herunder administrationen af information og opbevaring af elementer i en central database, følger best practice herfor.

Det er Leverandørens ansvar at varetage licensstyringen af både egne og KOMBITs licenser omfattet af Kontrakten. Licensstyringen skal sikre, at der til enhver tid er adgang til fyldestgø- rende information om licenser til brug for audit samt sikre, at audit ikke giver anledning til væ- sentlige eller kritiske anmærkninger.

Det er Leverandørens ansvar at sikre, at certifikater løbende opdateres i Systemet og i Drifts- miljøet, således at der ikke opstår Incidents grundet udløb af certifikater. Leverandøren skal

til enhver tid kunne præsentere en liste over de anvendte certifikater med angivelse af ud- løbsdato.

Alle registreringer omfattet af dette punkt 20 skal udleveres i en let overskuelig og systemati- seret oversigt ved Driftskontraktens ophør, jf. også Driftskontraktens punkt 31.3.

21 Knowledge Management

Knowledge Management omfatter at sikre, at alt relevant viden og information er tilgænge-

lig internt i Leverandørens organisation og for alle relevante Interessenter med henblik på at sikre høj kvalitet og effektivitet i Systemet, dets drift og anvendelse samt relaterede Ydel-

ser.

Leverandøren skal sikre relevant og tilstrækkelig vidensdeling internt i Leverandørens organi- sation, med Underleverandører samt med alle andre Interessenter til Systemet og Infrastruk- turen, herunder KOMBIT, Anvendersystemleverandører og Brugere, bl.a. i forbindelse med

opdatering af Systemet og Driftsmiljøet med nye Versioner/versioner og Patches. Leverandøren skal herunder levere følgende Ydelser:

• Foretagelse af vidensdeling med alle relevante Interessenter i forbindelse med væ-

sentlige ændringer i organiseringen omkring Infrastrukturdrift, Applikationsdrift og Ap- plikationsvedligehold.

• Foretagelse af vidensdeling med alle relevante Interessenter i forbindelse med Syste- mets og Driftsmiljøets opdatering med nye Versioner/versioner og Patches.

• Varsling om kommende ændringer til Eksterne Snitflader og funktionalitet i Systemet, herunder udfasning af tidligere versioner af Eksterne Snitflader til Systemet.

• Foretagelse af vidensdeling med Systemets Brugere, Leverandørens drifts- og sup- portpersonale, Underleverandører, KOMBIT, Anvendersystemleverandører mv. med relevant viden fra fejldiagnosticering og fejlrettelse, udvikling af ny Version, test og Prøver, risikovurdering under Change Management, idriftsættelse mv., herunder

kendte Fejl identificeret under eksempelvis test og Prøver, ændringer i Systemets an- vendelsesmuligheder med ny Version mv.

KAPITEL IV SERVICE DESIGN

22 Introduktion til Service Design

Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leveran- døren skal levere og opfylde som Service Design under Driftskontrakten.

Dette omfatter Ydelser og Servicemål inden for følgende ydelsesområder:

• Capacity Management, jf. punkt 23.

• Availability Management, jf. punkt 24.

• IT Service Continuity, jf. punkt 25.

• Information Security Management, jf. punkt 26.

• Supplier Management og Business Relations, jf. punkt 27.

• Overdragelsesplan og -test, jf. punkt 28 og 30.

• Deltagelse i overdragelse, jf. punkt 29 og 31.

23 Capacity Management

Leverandøren skal sikre, at der er tilstrækkelig kapacitet i miljøerne i Driftsmiljøet til at kunne levere Ydelserne i henhold til de aftalte Servicemål samt Driftskontraktens øvrige krav.

Leverandøren skal overvåge kapacitetsforbruget på alle relevante områder, eksempelvis,

men ikke afgrænset til, CPU, RAM, disk, netværk, database, bånd, mm. Målingerne af kapa- citetsforbruget skal være så hyppige og af en sådan karakter, at det vil være muligt for Leve- randøren rettidigt at spore selv mindre stigninger i forbrug, der kan fordre en udvidelse af ka- pacitet eller håndtering på anden vis.

Leverandøren skal kalenderkvartalsvis udarbejde kapacitetsprognoser, som udover at tage udgangspunkt i en fremskrivning af de målte kapacitetsforbrug også inkluderer påvirkning af sæsonudsving samt forretningsmæssige initiativer, eksempelvis installation af en ny Version eller indførelse af obligatorisk brug af Systemet.

Det er Leverandørens ansvar, at kapacitetsprognoser inddrager og tager højde for eventuelle relevante målinger af kapacitetsforbrug på Underleverandørers hardware. Dette med henblik på rettidigt at kunne foretage de nødvendige ændringer, inden Incidents opstår på grund af

kapacitetsmangel.

Leverandørens kvartalsvise kapacitetsprognoser skal leveres skriftligt til KOMBIT første Ar- bejdsdag i et kalenderkvartal, startende fra første kalenderkvartal efter beståelsen af Drifts- prøven.

Det er Leverandørens ansvar hurtigst muligt gennem anvendelse af Release and Deployment Management og Change Management processerne at afhjælpe kapacitetsproblemer, der ikke er forudset i kapacitetsprognoser.

Leverandøren skal registrere og opbevare de historiske målinger af kapacitetsforbruget.

24 Availability Management

Availability Management omfatter løbende reaktivt og proaktivt at sikre, at drift af Systemet i så stort omfang som muligt og på en omkostningseffektiv måde overholder krav og Service- mål for svartider og driftseffektivitet.

Leverandøren skal levere følgende Ydelser:

• Risikoanalyse

• Trendanalyse

• Identificering af forbedringsmuligheder til optimering af drift af Systemet

• Gennemførelse af relevante forbedringer til optimering af drift af Systemet

• Orientering af KOMBIT om risikoanalysen, trendanalysen, identificerede forbedrings- muligheder samt gennemførte forbedringer

Leverandøren skal mindst én gang årligt levere ovenstående Ydelser, idet der ikke må gå mere end 12 kalendermåneder mellem udførelsen af hver enkelt Ydelse.

Leverandøren skal foretage forebyggende vedligeholdelse af Driftsmiljøet. Dette omfatter at forebygge Incidents i driftsafviklingen af Systemet og Produktionsmiljøet for dermed at imø- degå risikoen for Systemets helt eller delvise utilgængelighed eller uanvendelighed. Dette

kan eksempelvis forekomme ved indikationer på kommende Incidents eller utilstrækkelig ka- pacitet på hardware eller hardwarekomponenter i Driftsmiljøet.

25 IT Service Continuity

Disaster Recovery omfatter at sikre en gennemførlig plan for genetablering af Systemet og Driftsmiljøet til normal driftsafvikling i tilfælde af alvorlig eller kritisk Incident.

Leverandøren skal levere følgende Ydelser:

• Udarbejdelse og vedligeholdelse af Disaster Recovery plan, jf. punkt 25.1

• Planlægning og gennemførelse af årlig Disaster Recovery test, jf. punkt 25.2

• Skriftlig afrapportering af testens resultater til KOMBIT, jf. punkt 25.2 og 25.3

25.1 Disaster Recovery plan

Leverandøren skal udarbejde en detaljeret Disaster Recovery plan, som vedlægges Drifts-

håndbogen, når denne leveres til KOMBIT. Disaster Recovery planen skal bl.a. redegøre for, hvordan uforudsete Incident håndteres, så datatab og nedetid minimeres. Se endvidere

punkt 25.2.

25.2 Disaster Recovery test

Leverandøren skal planlægge og gennemføre en Disaster Recovery test i og omkring en

weekend og i et tidsrum, som fastsættes af KOMBIT med mindst 120 Dages varsel, én gang per kalenderår. Disaster Recovery testen skal gennemføres i henhold til den under punkt

25.1 udarbejdede Disaster Recovery plan og skal overholde relevante Servicemål, eksempel- vis løsningstid for Incidents.

Scope for den årlige Disaster Recovery test udarbejdes inden testen i samarbejde med KOM- BIT. KOMBIT kan kræve, at Disaster Recovery testen udføres samtidig og integreret med til- svarende Disaster Recovery tests, der udføres på enkelte Anvendersystemer, som er væ-

sentlig for værdien af en samlet Disaster Recovery test på tværs af systemerne.

I dette tilfælde er Leverandøren forpligtet til at koordinere Disaster Recovery planen for og udførelsen af Disaster Recovery testen med Anvendersystemleverandørers tilsvarende pla- ner for og udførelse af Disaster Recovery test af de involverede Anvendersystemer. Planen skal tage højde for, at data og systemer genskabes i sammenhæng, således at testen kan

godtgøre, at en genetablering vil medføre en normal driftssituation for Systemet og de invol- verede Anvendersystemer.

Efter testens gennemførelse udarbejder Leverandøren på baggrund af testens resultater en rapport, som indeholder beskrivelser af opmærksomhedspunkter og problemstillinger, der

kan forringe betingelserne for eller forhindre en succesfuld Disaster Recovery, samt hand- lingsplaner med henblik på at adressere de identificerede problemstillinger.

25.3 Disaster Recovery rapport

Rapporten for gennemført Disaster Recovery test skal være KOMBIT i hænde senest 10 Ar- bejdsdage efter testens afslutning, medmindre andet er aftalt skriftligt.

Handlingsplanerne fra rapporten gennemføres indenfor 90 dage efter testens afslutning,

medmindre andet aftales. Handlingsplanerne kan af sikkerhedsmæssige årsager blive frem- rykket til hurtigere implementering end de 90 dage, efter aftale mellem KOMBIT og Leveran- døren.

25.4 Afprøvning af redundante setup i Produktionsmiljøet

Leverandøren skal senest 30 dage efter godkendt Driftsprøve samt efterfølgende en gang

hvert halvår gennemføre en afprøvning af det redundante setup i Produktionsmiljøet, såfremt dette forefindes. Ved afprøvning forstås at driften flyttes fra det primære setup til det redun- dante sekundære setup. Overflytningen skal påbegyndes i et af de fastlagte servicevindue,

og Systemet skal være fuldt fungerende i en uge på det sekundære setup, inden trafikken kobles tilbage på det primære setup i et af de fastlagte servicevinduer.

26 Information Security Management

Information Security Management omfatter at sikre planlægning, implementering, oprethol- delse, test og løbende forbedringer til sikkerhedsprocedurer og sikkerhedskontroller for data og information i Systemet og Driftsmiljøet.

Det er således afgørende for KOMBIT, at der er optimal sikkerhed omkring Systemet og data, der behandles i Systemet, og dermed afgørende for KOMBIT, at Leverandørens Information Security Management udføres som beskrevet nedenfor.

Leverandøren skal levere følgende Ydelser:

• Sikring af, at data og information i Systemet og Driftsmiljøet er tilgængeligt og anven- deligt, og at Systemet og Driftsmiljøet kan modstå sikkerhedsangreb (informationens tilgængelighed)

• Sikring af, at data og information i Systemet og Driftsmiljøet kun er tilgængeligt for Brugere med retmæssig adgang (informationens konfidentialitet)

• Sikring af, at data og information er komplet, korrekt og beskyttet mod uautoriseret modificering (informationens integritet)

• Sikring af troværdig og pålidelig udveksling af information med Anvendersystemer via Integrationer (informationens autencitet og uafviselighed)

• Udarbejdelse, implementering og vedligeholdelse af en sikkerhedspolitik for data og information i Systemet og Driftsmiljøet. Leverandøren skal implementere og vedlige-

holde processer og arbejdsprocedurer, som sikrer overholdelsen af den gældende sik- kerhedspolitik

• Foretagelse af løbende kontrol af, om sikkerhedspolitikken overholdes, bl.a. ved an- vendelse af stikprøvekontroller. Hvis der konstateres utilstrækkelig overholdelse af

sikkerhedspolitikken, skal Leverandøren på de identificerede problemer foretage korri- gerende aktiviteter, der kan sikre, at sikkerhedspolitikken overholdes fremadrettet. Le- verandøren skal sikre, at den fremadrettede kontrol verificerer, at de korrigerende ak- tiviteter har afhjulpet tidligere identificerede problemer

• Forhindring af Security Incidents, eksempelvis med effektiv adgangs- og rettigheds- kontrol til Systemet og Driftsmiljøet. Dette omfatter bl.a. at sikre, at kun nødvendige brugeradgange er aktive, eksempelvis ved systematisk nedlukning i forbindelse med

fratrædelse af medarbejdere, orlov mv., samt at der kun udleveres brugeradgange el- ler passwords til personer med verificeret, korrekt identitet

• Reducering af skadevirkningen af Security Incidents i Systemet og Infrastrukturen, herunder ved løbende Backup af data, jf. punkt 8

• Detektering af Security Incidents i Systemet og Infrastrukturen, så disse observe-

res så tidligt som muligt med henblik på hurtig iværksættelse af korrigerende handlin- ger, eksempelvis med effektiv Monitorering og effektiv antivirus

• Leverandøren skal implementere et intrusion detection and prevention system (IDPS), som overvåger, blokerer og alarmerer ved angreb på Systemet og Infrastrukturen. Sy- stemet skal inspicere så meget som muligt af den krypterede trafik.

• Modvirkning af den fortsatte skadevirkning af allerede indtrufne Security Incidents i Systemet og Infrastrukturen, eksempelvis med nedlukning af brugeradgang ved gen- tagne mislykkede forsøg på logon med forkert password

• Korrektion af skadevirkningen af Security Incident i Systemet og Infrastrukturen, f.eks. ved omgående Restore fra Backup

• Registrering af alle sikkerhedsbrud og Security Incidents i Systemet og Infrastruktu- ren, uagtet om disse er alvorlige eller ej

• Evaluering af alle sikkerhedsbrud og Security Incidents i Systemet og Infrastrukturen med henblik på at forbedre sikkerhedsniveauet, forhindre tilsvarende hændelser samt reducere skadevirkningen herved. Evalueringen skal omfatte en vurdering af, hvad der gik galt, hvad der forårsagede det, hvordan det kan forhindres fremadrettet, samt

hvordan skadevirkningen kan reduceres. Leverandøren skal uden ugrundet ophold im- plementere forbedringer til sikkerheden baseret på evalueringen

• Uden ugrundet ophold skriftlig orientering af KOMBIT om sikkerhedsbrud og Security Incidents, den gennemførte evaluering heraf samt foretagne eller planlagte forbedrin- ger til sikkerheden

• Planlægning og gennemførsel af en penetrationstest mindst en gang årligt, jf. punkt 26.1

• Deltagelse i kontrol af Leverandørens overholdelse af Driftskontrakten, jf. Driftskon- traktens punkt 18

26.1 Penetrationstest

Leverandøren skal planlægge og gennemføre en penetrationstest, jf. bilag 6, mindst en gang årligt med henblik på at verificere, at Systemet og Driftsmiljøet er underlagt tilstrækkelige sik- kerhedsforanstaltninger.

Testen skal udføres af en på feltet anerkendt ekspert.

Leverandøren skal sikre, at penetrationstesten planlægges med udgangspunkt i identificering af mulige sikkerhedstrusler for Systemet og Driftsmiljøet.

Leverandøren skal skriftligt orientere KOMBIT om den planlagte penetrationstest forud

for gennemførelsen, herunder hvem der påtænkes udpeget til at udføre testen. Derudover

skal KOMBIT orienteres om identificerede sikkerhedstrusler, omfanget af penetrationstesten samt planlagte test cases. Leverandøren skal sikre, at KOMBIT har mulighed for at tage stil- ling til og komme med forbedringsforslag til penetrationstesten. Leverandøren skal så

vidt muligt imødekomme KOMBITs ønsker om udpegelse af en alternativ ekspert til udførelse af testen samt ønsker til forbedringer til gennemførelse af penetrationstesten.

Leverandøren skal foretage en skriftlig rapportering til KOMBIT om resultatet af den gennem- førte penetrationstest.

Som opfølgning på penetrationstesten skal Leverandøren implementere forbedringer til sik- kerheden omkring Systemet og Driftsmiljøet, så evt. identificerede svagheder i sikkerhedsni- veauet eller identificerede Security Incidents adresseres.

26.2 Sikkerhedsrevisionserklæring

Leverandøren skal ved Driftskontraktens ikrafttræden levere en ISAE 3000 type 1 og en

ISAE 3402 type 1 erklæring, eller tilsvarende. Erklæringen skal dække Leverandørens drifts- ydelser og sikkerhed til KOMBIT i henhold til Driftskontrakten, herunder KOMBITs sikker-

hedspolitik, overholdelse af persondatalovens bestemmelser, ISO27001, kvalitets-sikrings- metoder og driftsprocedurer.

Leverandøren skal endvidere én gang årligt i Driftskontraktens løbetid levere en ISAE 3000 type 2 eller tilsvarende til KOMBIT. Erklæringen skal dække Leverandørens samt relevante

Underleverandørers driftsydelser og sikkerhed til KOMBIT, herunder Leverandørens Underle- verandørers overholdelse af persondatalovgivning og rets- eller administrativ praksis, der

måtte supplere og/eller erstatte disse regler, kvalitetssikringsmetoder, driftsprocedurer, Ser- vicemål mm. Erklæringen kan være af generel karakter og omfatte alle Leverandørens kun- der i det omfang, at ydelsen til KOMBIT falder ind under de generelle procedurer hos Leve- randøren. Hvis der anvendes en erklæring af generel karakter omfattende alle Leverandø-

rens kunder, skal Leverandøren sikre, at erklæringen udtrykkeligt redegør for, at erklæringen dækker Leverandørens og Underleverandørers driftsydelser og sikkerhed til KOMBIT samt

behandling af Anvendernes data. I året for Driftskontraktens ikrafttræden skal erklæringen dække perioden fra Overtagelsesdagen til 31. december. Erklæringen skal efterfølgende dække kalenderåret og afleveres til KOMBIT senest den 1. marts.

Herudover er KOMBIT berettiget til én gang i Driftskontraktens løbetid at kræve, at der gen- nemføres en ekstern audit specifikt af Ydelserne til KOMBIT, herunder KOMBITs sikkerheds- politik, ISO27001, Leverandørens og Underleverandørers overholdelse af kvalitetssikrings- metoder, driftsprocedurer, Servicemål, samt krav til Dokumentation, herunder Driftshåndbo- gen, jf. bilag 7.2.F, mm. Auditten skal resultere i en ISAE 3402 type 2 erklæring eller tilsva-

rende, specificeret til at omfatte Ydelserne til KOMBIT.

Leverandøren skal sikre, at Underleverandører i relevant omfang bliver auditeret samt dette detaljeret indgår i revisionserklæringerne.

Inden audit, som ligger til grund for revisionserklæringerne, påbegyndes, skal Leverandøren indarbejde KOMBITs skriftlige ønsker til specifikke emner, kontroller og områder, som skal med i den pågældende erklæring. Leverandøren skal inden gennemførsel af audit, frem-

sende et udkast til en revisionserklæring, som KOMBIT skal godkende skriftligt. Det skal af hver erklæring detaljeret fremgå, hvilke detaljerede observationer, der er gjort, og hvilke de- taljerede revisionshandlinger, der er udført for at nå til erklæringens konklusioner. Er der af- dækket risici og/eller svagheder hos Leverandøren og/eller Underleverandører, herunder i

relation til overholdelse af KOMBITs sikkerhedspolitik, Driftskontrakten, persondataloven,

ISO27001, Driftsmiljøet og/eller sikkerhedsprocedure, skal disse detaljeret fremgå af erklæ- ringen.

Leverandøren afholder alle udgifter til ovennævnte erklæringer.

KOMBIT er udover ovenstående berettiget til med et rimeligt varsel at få leveret og Leveran- døren forpligtet til at få udarbejdet yderligere erklæringer, herunder en systemspecifik ISAE 3402 type 2, idet KOMBIT i så fald afholder omkostninger i forbindelse med erklæringernes udarbejdelse, jf. punkt 11.2.1 og bilag 7.2.B.

27 Supplier Management og Business Relations

Leverandøren skal sikre, at kontrakter med Underleverandører samt interne aftaler i Leveran- dørens egen virksomhed understøtter Driftskontrakten på en måde, som sikrer, at Leveran-

døren kan leve op til sine forpligtelser i henhold til Driftskontrakten, herunder sikkerheds- mæssige krav.

Kontrakter med Underleverandører såvel som interne aftaler skal stilles til rådighed for KOM-

BIT i forbindelse med audits/kontrol, i det omfang, det er nødvendigt for en fyldestgørende audit. Leverandøren er ikke forpligtet til at fremvise dele af kontrakter med Underleverandø- rer, som omhandler økonomiske forhold.

Leverandøren skal sikre, at en audit kan inkludere dennes Underleverandører.

28 Plan for og test af Systemets overdragelse til Infrastruk- turdrift

KOMBIT kan træffe beslutning om, at Infrastrukturdriften skal overdrages fra Leverandøren til tredjemand. Systemet skal i den forbindelse overflyttes fra Driftsmiljøet til Andet Driftsmiljø.

Senest 180 Dage efter Leverandørens overtagelse af ansvaret for driften af Systemet skal Leverandøren have udarbejdet et udkast til en overdragelsesplan for fremtidig overdragelse af Infrastrukturdrift af Systemet til tredjemand, jf. Driftskontraktens punkt 30.

Overdragelsesplanen skal have en kvalitet og opdateres som beskrevet i Driftskontraktens punkt 30.

Overdragelsesplanen skal forelægges for KOMBIT til godkendelse. Når overdragelsesplanen er godkendt af KOMBIT, skal denne vedlægges som underbilag til nærværende bilag.

KOMBIT kan med henblik på at sikre, at det er muligt at driftsafvikle Systemet i Andet Drifts- miljø, anmode Leverandøren om at gennemføre en test af overdragelsen.

Overdragelsestesten skal gennemføres senest 25 Arbejdsdage efter KOMBITs anmodning herom, og ved, at Leverandøren:

1. Etablerer et Driftsmiljø, der består af de hardware- og softwaremæssige forudsætnin- ger, der er angivet under punkt 4 i bilag 7.2.C til brug for overdragelsestesten

2. Idriftsætter en kopi af Systemet og data i det etablerede Driftsmiljø

3. Gennemfører og består funktionel afprøvning og performance- og load-afprøvning i overensstemmelse med bilag 6

Testen skal gennemføres i overensstemmelse med planen for overdragelse af Systemet til Infrastrukturdrift hos tredjemand.

Testen udføres udelukkende baseret på det materiale, Leverandøren har leveret til KOMBIT, herunder Programmel, data, Dokumentation, herunder konfigurations- og installationsvejled- ninger og Konfigurationsmateriale. Leverandøren skal således demonstrere, at det til KOM-

BIT leverede materiale er tilstrækkeligt til at etablere Systemet til driftsafvikling i et andet driftsmiljø, jf. bilag 7.2.C.

Leverandøren rapporterer til KOMBIT om testresultatet senest 10 Arbejdsdage efter testens udførsel.

Såfremt der er uenighed om, hvorvidt ét eller flere af ovenstående krav til testen er opfyldt, afgøres uenigheden i overensstemmelse med Driftskontraktens punkt 33.2.

Vederlaget for overdragelsestesten afregnes særskilt til den i bilag 7.2.B angivne pris.

29 Deltagelse i overdragelse af Infrastrukturdrift

Såfremt KOMBIT træffer beslutning om, at Infrastrukturdriften skal overdrages fra Leverandø- ren til tredjemand, skal Leverandøren gennemføre overdragelsen af Systemet og data i over- ensstemmelse med planen herfor, jf. punkt 28. KOMBIT sikrer, at der indgås aftale med tred- jemand, hvortil Systemet overdrages til Infrastrukturdrift, om at samarbejde loyalt og aktivt

med Leverandøren om en gnidningsfri overflytning af Systemet.

Leverandøren skal planlægge og gennemføre overdragelsen af Systemet og data til Infra- strukturdrift hos tredjemand i samarbejde med denne og KOMBIT. Der skal i denne forbin-

delse blandt andet aftales en tidsplan for overdragelsen af Ydelserne indeholdende milepæle og datoer for alle relevante aktiviteter, herunder en dato, hvor alle relevante aktiviteter, eks. Prøver, skal være afsluttet i overensstemmelse med Parternes aftale med den følge, at den nye leverandør endeligt har overtaget ansvaret for Ydelserne, og Leverandørens ansvar her- for er ophørt. Den pågældende tredjemand deltager og stiller ressourcer til rådighed i nød-

vendigt og rimeligt omfang til, at Leverandøren kan gennemføre overdragelsen.

Leverandøren skal stille ressourcer og specialister til rådighed i nødvendigt og rimeligt om- fang, således at tredjemand har en reel mulighed for at kunne levere en infrastrukturdrifts- ydelse, som lever op til Driftskontraktens bestemmelser.

Leverandøren skal efter overdragelsen af Systemet og data til Infrastrukturdrift hos tredje- mand gennemføre en Driftsprøve á 30 Dages varighed. Driftsprøven skal gennemføres i

overensstemmelse med bestemmelserne i bilag 6.

Leverandøren får dækket rimeligt og dokumenteret tidsforbrug i forbindelse med overdragel- sen af Systemet til Infrastrukturdrift hos tredjemand, jf. Driftskontraktens punkt 31.5.

30 Plan og test af overdragelse af Infrastrukturdrift og Appli- kationsdrift

KOMBIT kan træffe beslutning om, at både Infrastrukturdriften og Applikationsdriften skal overdrages fra Leverandøren til tredjemand. Systemet skal i den forbindelse overflyttes fra Driftsmiljøet til Andet Driftsmiljø.

Senest 180 dage efter Leverandørens overtagelse af ansvaret for driften af Systemet skal

Leverandøren have udarbejdet et udkast til en overdragelsesplan for fremtidig overdragelse af Infrastrukturdriften og Applikationsdriften af Systemet til tredjemand, jf. Driftskontraktens punkt 30. Planen for overdragelse af Infrastrukturdriften og Applikationsdrift skal modsvare den tilsvarende plan for overdragelse af Infrastrukturdriften, som Leverandøren udarbejder i overensstemmelse med ovenstående punkt 28.

Overdragelsesplanen skal have en kvalitet og opdateres som beskrevet i Driftskontraktens punkt 30.

Overdragelsesplanen for Infrastrukturdrift og Applikationsdrift skal forelægges for KOMBIT til godkendelse. Når overdragelsesplanen er godkendt af KOMBIT, skal denne vedlægges som underbilag til nærværende bilag.

KOMBIT kan med henblik på at sikre, at det er muligt at driftsafvikle Systemet i Andet Drifts- miljø, anmode Leverandøren om at gennemføre en test af overdragelsen.

Overdragelsestesten skal gennemføres senest 25 Arbejdsdage efter KOMBITs anmodning herom, og ved, at Leverandøren:

1. Etablerer et Driftsmiljø, der består af de hardware- og softwaremæssige forudsætnin- ger, der er angivet i punkt 4 i bilag 7.2.C til brug for overdragelsestesten

2. Idriftsætter en kopi af Systemet og data i det etablerede driftsmiljø

3. Gennemfører og består funktionel afprøvning og performance- og load-afprøvning i overensstemmelse med bilag 6

Testen skal gennemføres i overensstemmelse med planen for overdragelse af Systemet til Infrastrukturdrift og Applikationsdrift hos tredjemand.

Testen udføres udelukkende baseret på det materiale, Leverandøren har leveret til KOMBIT, herunder Programmel, data, Dokumentation, herunder konfigurations- og installationsvejled-

ninger og Konfigurationsmateriale. Leverandøren skal således demonstrere, at det til KOM-

BIT leverede materiale er tilstrækkeligt til at etablere Systemet til driftsafvikling i et andet driftsmiljø, jf. bilag 7.2.C.

Leverandøren rapporterer til KOMBIT om testresultatet senest 10 Arbejdsdage efter testens udførsel.

Såfremt der er uenighed om, hvorvidt ét eller flere af ovenstående krav til testen er opfyldt, afgøres uenigheden i overensstemmelse med Driftskontraktens punkt 33.2.

Vederlaget for overdragelsestesten afregnes særskilt til den i bilag 7.2.B angivne pris.

31 Deltagelse i overdragelse af Infrastrukturdrift og Applika- tionsdrift

Ved en eventuel opsigelse af Infrastrukturdriftsopgaverne og Applikationsdriftsopgaverne,

forventes der fortsat drift, vedligeholdelse, support og videreudvikling af Systemet og Drifts- miljøet, indtil driften er overtaget af tredjemand. Leverandøren skal sikre en gnidningsfri

overflytning af Infrastrukturdrift og Applikationsdrift til tredjemand, jf. Driftskontraktens punkt 31.

Overdragelsen af Infrastrukturdriften og Applikationsdriften fra Leverandøren til tredjemand, herunder overdragelsen af Systemet og data, skal ske i overensstemmelse med planen her- for, jf. punkt 30. KOMBIT sikrer, at der indgås aftale med tredjemand, hvortil Systemet over- drages til Infrastruktur- og Applikationsdrift, om at samarbejde loyalt og aktivt med Leveran- døren om en gnidningsfri overflytning af Systemet.

Leverandøren skal i hele processen loyalt og aktivt medvirke til at fremme overdragelsen af Infrastrukturdriften og Applikationsdrift til tredjemand, herunder aktivt samarbejde med den pågældende tredjemand og KOMBIT. Der skal i denne forbindelse blandt andet aftales en

tidsplan for overdragelsen af Ydelserne indeholdende milepæle og datoer for alle relevante aktiviteter, herunder en dato, hvor alle relevante aktiviteter, eks. Prøver, skal være afsluttet i overensstemmelse med Parternes aftale med den følge, at den nye leverandør endeligt har overtaget ansvaret for Ydelserne, og Leverandørens ansvar herfor er ophørt.

Leverandøren skal aktivt bidrage til planlægning og gennemførelse af overdragelsen og i den forbindelse stille ressourcer og specialister til rådighed i nødvendigt og rimeligt omfang, såle- des at tredjemand har en reel mulighed for at kunne levere en infrastrukturdriftsydelse og ap- plikationsdriftsydelse, som lever op til Driftskontraktens bestemmelser.

Leverandøren får dækket rimelige og dokumenteret tidsforbrug i forbindelse med overdragel- sesopgaven, jf. Driftskontraktens punkt 31.5.

Document Metadata

Table of Contents

Instruktion til tilbudsgiver

Document Metadata