Instruktion til tilbudsgiver
Bilag 7.2.A Ydelser og Servicemål |
Samarbejdsplatformen |
Instruktion til tilbudsgiver
Nærværende bilag indeholder en beskrivelse af de Ydelser, som Leverandøren skal levere i henhold til Driftskontrakten, og Servicemålene herfor, hvor Leverandø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 markeret med […]. For nærværende bilag betyder det, at Tilbudsgiver skal:
• angive kontaktperson til rapportering af Incidents, jf. punkt 7.8
• angive kontaktperson til Service Desk, jf. punkt 10.1.
bilag et skal ikke herudover udfyldes af Tilbudsgiver, idet Tilbudsgivers besvarelse af øvrige dele af bilag et skal ske ved at udfylde bilag 7.2.A.1 i henhold til instruktionerne angivet i bi- lag 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 bilag et der er besvaret af Tilbudsgiver. Anvendelse af ændringsmarkering er reserveret til Tilbudsgivers eventuelle forbehold.
Tilbudsgivers eventuelle forbehold til bilag 7.2.A anføres i forbeholdslisten og skrives ind med ændringsmarkering i selve bilag et i overensstemmelse med udbudsbetingelserne.
Det bemærkes, at Kontrakten uden bilag og Driftskontraktens bilag 7.2, 7.3 og 7.4 udgør mi- nimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor, jf. udbudsbetingelserne. Til- budsgiver skal derfor sikre, at eventuelle forbehold til bilag 7.2.A ikke udgør et forbehold overfor Kontrakten uden bilag og Driftskontraktens 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 Tilbuds- giver ikke kan tage forbehold overfor:
• Punkt 7.7 med underpunkter
• Punkt 13 med underpunkter
• Punkt 14 med underpunkter
• Punkt 19.1 med underpunkter
Om betydningen og vurderingen af Tilbudsgivers besvarelse af instrukser og eventuelle for- behold til bilag et henvises til udbudsbetingelserne.
Indholdsfortegnelse
2.2 Generelt om Leverandørens Ydelser 8
2.4 Kritiske Servicemål og Kritiske ikke-månedlige Servicemål 9
KAPITEL II Service Operation 11
3 Introduktion til Service Operation 11
4 Monitorering og Event Management 11
5 Driftsafvikling af Batchkørsler 12
5.1 Servicemål for Batchkørsler 13
7.1 Generelle krav til Leverandørens Incident Management 15
7.2 Indrapportering af information om Incidents 16
7.3 Prioritering af Incidents 16
7.4 Kategorisering af Integrationer til incidentprioritering 19
7.5 Kategorisering af Batchkørsler til Incidentprioritering 20
7.7 Servicemål for Incident Management 23
7.8 Kontaktperson til KOMBITs rapportering af Incidents 26
7.9 Eskalering til KOMBIT samt orientering om Incidents til Brugere og øvrige Interessenter 26
7.10 Afslutning på Incident Management processen 27
8.2 Ydelser under Problem Management 29
8.3 Prioritering af Problems 30
8.4 Problems, som Leverandøren er ansvarlig for 31
8.5 Problems, som Leverandøren ikke er ansvarlig for 31
8.6 Servicemål for Root Cause Analyser 31
9.2 IT Service Management system 33
9.3 Systemets dertil indrettede hjemmeside 34
9.4 Servicemål for Service Desk 35
9.5 Dokumentation af henvendelser til Service Desk 37
10.1 Indrapportering af information om Service Requests 38
10.2 Servicemål for Service Requests 38
12.1 Servicemål for Applikationsdrift 42
12.2 Servicemål for Infrastrukturdrift 44
12.3 Kombineret Tilgængeligheds Servicemål 46
12.4 Systemets brugeroplevede driftseffektivitet 46
12.5 Oversigt over Servicemål for Applikationsdrift og Infrastrukturdrift 46
13.2 Modregning af svartid udenfor Systemet 48
13.3 Svartider for transaktioner i brugergrænsefladen 48
13.4 Svartider for Servicetransaktioner i Eksterne Snitflader 52
13.5 Kontrolmåling af svartider 57
13.6 Opgørelse af svartider samt tidsrum med driftsforstyrrelser for Afsendersystemer 58
KAPITEL III Service Transition 59
14 Introduktion til Service Transition 59
15.1 Servicemål for Change Management 60
15.2 Risikovurdering af RfC 61
17 Release and Deployment Management 62
17.1 Vedligeholdelse af Systemet og Driftsmiljøet med nye Versioner/Versioner af Programmel/programmel 63
17.2 Vedligeholdelse af Systemet med nye Versioner af Tredjepartsprogrammel 65
17.3 Vedligeholdelse af Integrationer 65
17.5 Servicevinduer til vedligeholdelse 66
17.6 Plan for nye Versioner 67
18.1 Servicemål for Patch Management 68
19 Asset- og Configuration Management 69
21 Introduktion til Service Design 72
24.1 Disaster Recovery plan 73
24.2 Disaster Recovery test 73
24.3 Disaster Recovery rapport 74
24.4 Afprøvning af redundant setup i Produktionsmiljøet 74
25 Information Security Management 75
25.2 Sikkerhedsrevisionserklæring 77
26 Supplier Management og Business Relations 77
27 Plan for og test af Systemets overdragelse til Infrastrukturdrift 78
28 Deltagelse i overdragelse af Infrastrukturdrift 79
29 Plan for og test af Systemets overdragelse af Infrastrukturdrift og Applikationsdrift . 79
30 Deltagelse i overdragelse af Infrastrukturdrift og Applikationsdrift 80
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 0, der indeholder indled- ning og generelle bestemmelser for Leverandørens Ydelser.
KAPITEL I indeholder krav og Servicemål til Leverandørens driftsafvikling samt Ydelser un- der Service Operation.
KAPITEL II indeholder krav og Servicemål til Leverandørens Ydelser under Service Transi- tion.
KAPITEL III 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.
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 Definition | Beskrivelse af afvigelse fra standard ITIL v3 definitionen |
Access Management | Ja | |
Asset Management | Ja | |
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 | |
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 | |
Incident Management | Ja | |
Incident Record | Ja | |
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åleperiode.
- Måleperioden: 00.00 til 24.00 alle dage
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
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 afhjælpning af prioritet A og B Problems angivet under punkt 9.3.1
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 6.
• 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 I SERVICE OPERATION
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.
Dette omfatter Ydelser og Servicemål inden for følgende ydelsesområder:
• Monitorering og Event Management, jf. punkt 4
• Driftsafvikling af Batchkørsler, jf. punkt 5
• Backup og Restore, jf. punkt 6
• Incident Management, jf. punkt 7
• Problem Management, jf. punkt 8
• Request Fulfilment, jf. punkt 11
• Access Management, jf. punkt 12
• Servicemål for drift, jf. punkt 13
• Systemets svartider, jf. punkt 14
Leverandørens rapportering vedrørende driftssituationen, herunder Dokumentation for over- holdelse af krav og Servicemål, er yderligere reguleret i bilag 7.2.G.
Monitorering og Event 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 f.eks. 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
4.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.
4.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 transaktionslogs, databaselogs, backuplogs, event- logs og accesslogs.
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 mod Afsendersystemer.
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.
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 tidsrummene for planlagte Batchkørsler er optimale. Hvis der vurderes at være behov for ændringer, ændres tidsrummet
i overensstemmelse hermed, hvorefter dette opdateres i Dokumentationen i bilag 7.2.F. Så- fremt der er uenighed mellem Parterne i forhold til fastsættelsen af tidsrummet for planlagte Batchkørsler, eskaleres og løses Parternes uenighed i overensstemmelse med Driftskontrak- tens punkt 33.2.
Såfremt det ikke lykkes at gennemføre en planlagt Batchkørsel succesfuldt, skal Leverandø- ren sikre, at Systemet er i en stabil tilstand, og at den planlagte Batchkørsel bliver gennem- ført korrekt og uden Fejl hurtigst muligt i tæt dialog og samarbejde med evt. involverede An- vendersystemleverandører og under hensyntagen til alvorligheden i effekten af den fejlede Batchkørsel.
Såfremt en Batchkørsel kun er driftsafviklet delvist, forsinket eller på anden måde fejlet, håndteres forholdet som et Incident, herunder i overensstemmelse med Incident prioriterin- gen under punkt 7.3 og de Servicemål, som er gældende for håndtering af Incidents, jf. punkt 7.7.
5.1 Servicemål for Batchkørsler
Kategori | Servicemål |
Kritisk Batchkørsel | Skal være gennemført succesfuldt til aftalt tid i 100 % af tilfældene |
Vigtig Batchkørsel | Skal være gennemført succesfuldt til aftalt tid i 95 % af tilfældene |
Mindre Vigtig Batchkørsel | Skal være gennemført succesfuldt til aftalt tid i 90 % af tilfældene |
Tabel 2: Servicemål for Batchkørsler
Kategoriseringen af Batchkørsler er beskrevet i punkt 7.5.
Kompleksitet | Aftalt tid |
Simpel Batchkørsel | < 1 time |
Middel Batchkørsel | < 3 timer |
Kompleks Batchkørsel | < 5 timer |
Tabel 3: Servicemål for Batchkørsler - aftalte tider
Kompleksitet definerer den tid, som en Batchkørsel maksimalt må tage. Kompleksitetsgraden 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.
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.
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 et Incidents indvirkning på Anvendernes virksomhed og aktivi- teter begrænses mest muligt.
Incident Management processen skal gennemføres i overensstemmelse med følgende pro- ces:
1) Et Incident konstateres, indrapporteres og prioriteres, jf. punkt 7.2 - 7.5.
2) Leverandøren iværksætter alle aktiviteter, der er nødvendige for at få et Incident løst, jf. punkt 7.6, og alle øvrige aftalte aktiviteter inden for de aftalte Servicemål herfor, jf. punkt 7.7.
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.
7.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 registreres med direkte indbyrdes relationer med henblik på at bidrage til en effektiv håndtering.
• Foretage klassificering af Incidents for efterfølgende at kunne identificere relevante indsatsområder med henblik på bl.a. at reducere antallet af In- cidents. Klassificeringen kan eksempelvis basere sig på typer som gen- tagne Incidents, hardware Incidents, Incidents på Integrationer mv.
• Prioritere Incidents i henhold til punkt 7.3 - 7.5.
• Eskalering af Incidents til Tredjepartsprogrammelleverandør ved Inci- dent, hvor årsagen til Incidentet skyldes eller kan skyldes forhold i Tred- jepartsprogrammel fra den pågældende Tredjepartsprogrammelleveran- dør.
• Eskalering af Incidents til Anvendersystemleverandør ved Incident, hvor årsagen til Incidentet skyldes eller kan skyldes forhold hos den pågæl- dende Anvendersystemleverandør, herunder fejl i data.
• Løbende opfølgning på Incidents, herunder navnlig Incidents, der er eskaleret til Tredjepartsprogrammelleverandører samt Anvendersystem- leverandø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 Anvendersystemle- verandør.
• Såfremt eskalering er foretaget til tredjepart, skal Leverandøren fortsat aktivt afsøge andre, også mindre sandsynlige, årsager til Incidentet samt muligheder for løsning af Incidentet.
• Rekvirering af Root Cause Analyse for alle prioritet A og B Incidents fra Anvendersystemleverandører eller Tredjepartsprogrammelleverandør og fremsendelse af analysen til KOMBIT. Såfremt Anvendersystemleveran- dør eller Tredjepartsprogrammelleverandør ikke efterkommer anmodning om Root Cause Analyse, eskaleres sagen af Leverandøren til KOMBITs driftschef eller dennes repræsentant.
• Løbende informering af den person, der har henvendt sig med Incident, om Incidentets 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.
7.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 et Incident Record og registrere følgende informa- tion:
• Unik identifikation
• Tidspunkt for Incidentets 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 Incidentet
• Kontaktperson i organisationen, der indrapporterede den pågældende Incident
• Beskrivelse af Incidentet, hvilket omfatter beskrivelse af den observerede Incident, den observerede konsekvens, den Event, og/eller om muligt den Root Cause, der for- årsager Incidentet, samt udført handling og opnået reaktion herpå
• Forslag til incidentprioritering, herunder kategorisering, jf. punkt 7.3, 7.4 og 7.5
• Eventuelle bilag til belysning af Incidentet, 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 7.2 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
Starttiden for et Incident (”Incidentstarttiden”) er, når Leverandøren som led i sin Incident Ma- nagement proces, f.eks. ved en Event, eller i forbindelse med modtagelse af henvendelse til Service Desk eller til kontaktpersonen, jf. punkt 7.8, konstaterer eller burde have konstateret et Incident.
Incidentstarttiden kan aldrig være senere end henvendelsestidspunktet.
7.3 Prioritering af Incidents
[Punkt 7.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 | Incidentet har eller vil have kritisk indvirkning på Systemet og/eller løsningen af de opga- ver, som Systemet an- vendes til eller for. | Et Incident har f.eks. kritisk indvirkning, hvis en eller flere af følgende betingelser opfyldes: • Incidentet 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. |
Incidentprioritet | Beskrivelse | Eksempler i Produktionsmiljøet |
• Incidentet indebærer en kritisk forringelse af Systemets anvendelse, f.eks. i form af føl- gende: o Systemet er utilgængeligt for alle Bru- gere hos én eller flere Anvendere; o Systemet og/eller afgørende funktionali- tet er utilgængeligt for mere end 20 % af samtlige Brugere; o Incidentet indebærer ukorrekte beregnin- ger i Anvendersystemer; o Incidentet indebærer, at kritisk funktiona- litet er utilgængelig; o Der sker nedbrud på netværksforbindel- ser, herunder til tredjeparter; • En Kritisk Batchkørsel, jf. punkt 7.5 fejler; • En Kritisk Integration, jf. punkt 7.4, fejler; • 3 Vigtige Integrationer, jf. punkt 7.4 fejler; • Overskridelse af Servicemål for Xxxxxxxxx Xxxxxxxxx, jf. punkt 14.3 og 14.4 med under- punkter. | ||
Prioritet B Alvorlig Incident | Incidentet har eller vil have alvorlig indvirkning på Systemet og/eller løsningen af de opga- ver, som Systemet an- vendes til eller for. | Et Incident har f.eks. alvorlig indvirkning, hvis en eller flere af følgende betingelser opfyldes: • Incidentet har alvorlig indvirkning på anven- delsen af Systemet, herunder på funktionali- tet, indeks, tabeller eller data, som Syste- met udstiller fra Anvendersystem, som Sy- stemet er tilsluttet, eller Systemets interne 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 7.4, fejler • 3 Mindre Vigtige Integrationer, jf. punkt 7.4, fejler; • En Vigtig Batchkørsel, jf. punkt 7.5, fejler; • En Mindre Vigtig Batchkørsel, jf. punkt 7.5, fejler gentagende gange; • En Mindre Vigtig Integration, jf. punkt 7.4, 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 |
Incidentprioritet | Beskrivelse | Eksempler i Produktionsmiljøet |
end 2 timer, medmindre andet fremgår af Leverancebeskrivelsen; • Overskridelse af Servicemål for Ønskede Svartider, jf. punkt 14.3 og 14.4 med under- punkter; | ||
Prioritet C Betydende Inci- dent | Incidentet har eller vil have betydende indvirk- ning på Systemet og/el- ler løsningen af de op- gaver, som Systemet anvendes til eller for. | Et Incident har f.eks. betydende indvirkning, hvis en eller flere af følgende betingelser op- fyldes: • Et 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 7.4, fejler; • En Mindre Vigtig Batchkørsel, jf. punkt 7.5, fejler |
Prioritet D Mindre bety- dende Incident | Incidentet har eller vil have mindre betydende indvirkning på Systemet og/eller løsningen af de opgaver, som Systemet anvendes til eller for. | Et Incident har f.eks. mindre betydende ind- virkning, hvis følgende betingelse opfyldes: • En mindre betydende Incident, som medfø- rer gene for Brugere eller Anvendere, men ikke blokerer for anvendelse; |
Tabel 4: 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 Incidentet skal løses af og dermed ved eskalering til tredjemand.
Ved uenighed om et Incidents prioritering, eller hvorvidt Incidentet skal løses af og ved eska- lering 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 alternativ 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ølgende eska- lation i overensstemmelse med Driftskontraktens punkt 33.2.
Indtil spørgsmålet om prioritering af og/eller ansvaret for løsningen af Incidentet er afgjort, skal Leverandøren håndtere dette i henhold til KOMBITs beslutning. Viser det sig efterføl- gende gennem fælles erkendelse eller den sagkyndiges afgørelse, at Incidentet 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 et Incident. Dette princip illustreres ved følgende ek- sempler:
Leverandøren burde have konstateret en prioritet A Incident mandag kl. 9.00.
- Servicemålene for prioritet A Incidents gælder fra mandag kl. 9.00, uanset om Leve- randøren først konstaterer og/eller prioriterer Incidentet mandag kl. 10.00.
- Servicemålene for prioritet A Incidents gælder ligeledes fra mandag kl. 9.00, uanset om Leverandøren – med eller uden indsigelser fra KOMBIT – prioriterer Incidentet ukorrekt, eksempelvis som en prioritet B Incident.
7.4 Kategorisering af Integrationer til incidentprioritering
[Punkt 7.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 et 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 7.3, kategoriseres alle Inte- grationer i følgende kategorier:
Integrationskategorier | Eksempler på Integrationer i Produktionsmiljøet | Incidentprioritering |
Kritisk Integration Integrationen har kritisk betydning for Systemet og/eller løsningen af de opgaver, som Systemet anvendes 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 f.eks. data om systemers og brugeres rettigheder. | 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 Systemet anvendes til eller for. | • En Integration til et andet sy- stem som er delvist afhængig af Integrationen i forbindelse med udbetalinger eller afgørelser i myndighedssager. • 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. F.eks. 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 |
Integrationskategorier | Eksempler på Integrationer i Produktionsmiljøet | Incidentprioritering |
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. | Fejl og andre driftsforstyr- relser ved sådanne Inte- grationer skal som Incident prioriteres som prioritet C |
Tabel 5 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 et 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 et 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.
7.5 Kategorisering af Batchkørsler til Incidentprioritering
[Punkt 7.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 et 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 7.3, kategorise- res alle Batchkørsler i følgende kategorier:
Batchkørsel kategorier | Eksempler på Batchkørsler i Pro- duktionsmiljøet | Beskrivelse |
Kritisk Batch- kørsel | En Kritisk Batchkørsel kan f.eks. være: | Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som In- cident prioriteres som prioritet A |
Batchkørsel kategorier | Eksempler på Batchkørsler i Pro- duktionsmiljøet | Beskrivelse |
• En Batchkørsel, hvor et andet system er afhængig af Batch- kørslen i forbindelse med udbe- talinger eller afgørelser isager. • En Batchkørsel, som påvirker et andet system, som anvendes af mindst 5 Anvendere • Batchkørslen indeholder kritisk data fra Anvendersystemer f.eks. vedrørende sikkerhed el- ler masseopdateringer fra regi- stre. | ||
Vigtig Batch- kørsel | En Vigtig Batchkørsel kan være: • En Batchkørsel, hvor et andet system er delvist afhængig af Batchkørslen i forbindelse med udbetalinger eller afgørelser i myndighedssager. • En Batchkørsel som påvirker et andet system som anvendes af mindst 2 Anvendere • Batchkørslen indeholder vigtig data fra Anvendersystemer f.eks. indlæsning eller udtræk af data, som indeholder person- data, som er følsomme eller se- mifølsomme. | Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som In- cident prioriteres som prioritet B |
Mindre Vigtig Batchkørsel | En Mindre Vigtig Batchkørsel kunne f.eks. være: • En Batchkørsel, som påvir- ker et andet system, hvis An- vendere 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 6: 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 Kritisk 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 et Incident med ét niveau, hvis en konkret Batchkørsel vurderes som mindre vigtig end be- skrevet, jf. følgende eksempel. KOMBIT kan afvise et ønske fra Leverandøren om at nedgra- dere prioriteten af et Incident.
Eksempel:
Der konstateres en Fejl ved afvikling af en Kritisk Batchkørsel. Der oprettes et prioritet A Incident på Fejlen. Indledende fejlsøgning afdækker, at Incidentet ikke har eller kan have kritisk indvirkning på Systemet. KOMBIT orienteres herom, og hvis KOMBIT skriftligt er- klærer sig enig i vurderingen, nedgraderes Incidentet fra prioritet A til prioritet B.
Tilsvarende kan en Fejl i en Vigtig Batchkørsel nedgraderes fra prioritet B til prioritet C Incident, og en Fejl i en Mindre Vigtig Batchkørsel nedgraderes fra prioritet C til D Inci- dent, hvis KOMBIT forinden er hørt herom og skriftligt har erklæret sig enig i Leverandø- rens vurdering.
7.6 Løsning af Incidents
[Punkt 7.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 7.6.1, eller afhjælpning, jf. punkt 7.6.2. Uanset, om Incidents løses ved Omgåelse eller afhjælpning, skal Leverandøren udføre alle aktivite- ter, der er nødvendige for at løse Incidents i henhold til de Servicemål, der fremgår af punkt 7.7, herunder ved levering af nødvendigt supplerende Infrastruktur, Programmel, programmel i Driftsmiljøet og konsulentbistand. Arbejdet med løsningen af Incidents skal derudover over- holde Driftskontraktens garantier og øvrige bestemmelser, jf. herunder Driftskontraktens punkt 5 og 6.
[Punkt 7.6.1 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Ved Omgåelse fjernes Incidentets effekt på og/eller risiko for effekt på Systemets anvendelig- hed således, at Systemet lever op til Kontraktens krav og bestemmelser, og/eller at risikoen for driftsforstyrrelser i Systemets anvendelighed er fjernet. Ved Omgåelse sker der ikke elimi- nering af Incidentets Root Cause. For at en fuldstændig Omgåelse af et Incident kan accep- teres som løsning af et 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
[Punkt 7.6.2 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Ved afhjælpning fjernes dels Incidentets effekt på og/eller risiko for effekt på Systemets an- vendelighed som ved Omgåelse, dels Incidentets 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
7.6.3 Leverandørens generelle ansvar
Leverandøren har uanset, hvor et 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 fejlen/forholdet, der forårsagede Incidentet, er afhjulpet, skal Leverandøren uden ugrun- det ophold sikre, at Kontraktens krav er opfyldt, herunder at Systemet anvender Integrationer korrekt.
7.7 Servicemål for Incident Management
[Punktet 7.7 med underpunkter udgør minimumskrav, som Tilbudsgiver ikke kan tage forbe- hold overfor].
Servicemål for Incident Management baserer sig på reaktionstider, jf. punkt 7.7.1, løsningsti- der, jf. punkt 7.7.2, og eskaleringstider, jf. punkt 7.7.3.
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, jf. punkt 7.7.2. 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, jf. punkt 7.7.4, selvom Incidentet har prioritet A eller B.
Såfremt Leverandøren ikke har opfyldt kravene til Monitorering og Event Management, jf. punkt 4, og et 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 7.7.4.
Reaktionstiden er fra Incidentstarttiden, jf. punkt 7.2, til Leverandøren har gennemført regi- strering af et Incident Record, herunder forslag til klassificering og forslag til prioritering af den pågældende Incident, samt har påbegyndt diagnosticeringen, samt reageret overfor in- volverede parter. Servicemål for reaktionstiden gælder, uanset om Incidents, herunder Fejl, skyldes Leverandørens forhold eller andre forhold, herunder Tredjepartsprogrammelleveran- dører eller Anvendersystemleverandører.
Løsningstiden er fra Incidentstarttiden, jf. punkt 7.2, til Leverandøren har løst Incidentet i overensstemmelse med punkt 7.6 og dette punkt 7.7.2.
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 Incidentet, jf. punkt
7.6. Såfremt dette ikke er muligt, skal Leverandøren i videst muligt omfang søge at begrænse Incidentets påvirkning af Systemets anvendelse. Dette kan eksempelvis omfatte, at Leveran- døren tydeligt informerer KOMBIT om alternativ arbejdsgang for Systemets anvendelse (Om- gåelse). Såfremt dette ikke er muligt, skal Leverandøren skriftligt inden for løsningstiden do- kumentere, hvorfor det ikke er muligt for Leverandøren at løse Incidentet, herunder udar- bejde et udkast til en skriftlig orientering af berørte Interessenter, jf. punkt 7.9, som skal fore- lægges KOMBIT til godkendelse. Leverandøren skal efter KOMBITs godkendelse udsende den skriftlige orientering til Interessenterne i en form, som er aftalt med KOMBIT.
Eskaleringstiden regnes fra Incidentstarttiden, jf. punkt 7.2, til Leverandøren har orienteret Anvendersystemleverandøren og/eller Tredjepartsprogrammelleverandøren om forholdet. Eskaleringstider måles alene inden for Tredjepartsprogrammelleverandørens eller Anvender- systemleverandø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.
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 et Incident til en Anvendersystemleverandør eller en Tredjepartspro- grammelleverandør, og viser det sig efterfølgende, at Leverandøren selv var ansvarlig for In- cidentet, beregnes løsningstiden i overensstemmelse med de definerede Servicemål herfor, 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.
Servicemål angivet i nedenstående Tabel 7 og Fejl! Henvisningskilde ikke fundet. skal op- fyldes med 90 % fraktilen for alle målte tider i løbet af en kalendermåned.
Servicemål for Incident Management i perioden | 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 | 15 Arbejdsdage, medmindre Parterne aftaler andet |
Tabel 7: Servicemål for Incident Management
7.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 nedenstående kontaktperson. Adgangen til telefonisk indrappor- tering skal gælde 24/7 for så vidt angår Incidents, der kandiderer til prioritet A eller B.
Navn, stilling for Incident Manager | Tlf. Mobil Mail |
[Udfyldes af Tilbudsgiver] | [Udfyldes af Tilbudsgiver] |
Tabel 8: Kontaktperson til KOMBIT
7.9 Eskalering til KOMBIT samt orientering om Incidents til Brugere og øvrige Interes- senter
For alle Incidents, der er prioriteret som prioritet A og B, og uanset om Incidentet 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 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 at deltage i løbende telefonmøder omkring status på Incidentet, 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.
7.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 Interessenter med driftsstatus
• Leverandøren skal mindst hver anden time opdatere både driftschef eller denne re- præsentant per telefon eller efter aftale samt opdatere den dertil indrettet hjemmeside og/eller mail.
• Leverandøren skal løbende orientere om status på prioritet A og B Incidents på den dertil indrettet hjemmeside og/eller mail til berørte Brugere og Interessenter med en frekvens på ikke mindre end 2 timer.
Tiden for orientering af KOMBITs driftschef eller dennes repræsentant måles fra Incident- starttiden, jf. punkt 7.2, til Leverandøren har meddelt Incidentet til KOMBITs driftschef eller dennes repræsentant. Leverandøren skal i IT Service Management systemet logge tidspunk- ter 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, jf. punkt 7.2, til
Leverandøren har informeret Xxxxxxx og Interessenter på den anførte måde.
7.10 Afslutning på Incident Management processen
Et Incident anses først som afsluttet, når det er løst i overensstemmelse med kravene i punkt 7.6, og KOMBITs driftschef har modtaget Leverandørens skriftlige orientering herom.
Leverandøren skal senest 2 Dage efter, at et Incident med prioritet A eller B er løst, jf. punkt 7.6, fremsende et Incidentrapport til KOMBIT. I det tilfælde, at et Incident løses på en ikke- Arbejdsdag, og de to efterfølgende Dage heller ikke er Arbejdsdage, gælder dog, at incident- rapporten 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, Incidentets art, Root Cause herfor og den foretagne løsning samt en angivelse af
• Om de(n) pågældende Incident(s) er eskaleret til Problem Management, jf. punkt 8, 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 et 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 Incidentet 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.
Et Incident Record lukkes først, når Incidentet er afhjulpet, jf. punkt 7.6.2. Dermed forbliver Incident Record åben, så længe et Incident ikke er løst eller er løst ved Omgåelse, jf. punkt 7.6.1.
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 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.1.
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.
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. Incidentet har eller har haft prioritet A eller B.
2. Incidentet har eller har haft prioritet C eller D, og Incidentet 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.
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.1 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.3, samt bistå med afhjælpning af Problems, som Le- verandøren ikke er ansvarlig for, jf. punkt 9.4.
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.2
• Identificering og dokumentering af Root Cause for Problems
• Leverandøren skal, på KOMBITs anmodning, anmode Tredjepartspro- grammelleverandø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 Tredjepartsprogrammel eller Anven- dersystemer
• 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 om- fatter at opdatere Known Error Database. Ved forebyggende vedligehol- delse 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.2 Prioritering af Problems
Alle Problems prioriteres i prioritet A, B, C eller D i henhold til prioriteten for det 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 et 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 priorite- res 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 et Incident i forbindelse med og/eller som følge af Incident Manage- ment processen nedprioriteret, skal det Problem, der har været årsag til den pågældende Incident, prioriteres i overensstemmelse med den høje- ste prioritering, der har været under Incident Management processen.
For de Problems, som ikke direkte eller indirekte er oprettet på baggrund af et 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.3 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.3.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.3.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 9 Servicemål for afhjælpning af Problems
Afhjælpningstiden er tiden fra indrapportering af et Problem, jf. punkt 9, til Leverandøren har afhjulpet det pågældende Problem i Systemet i Driftsmiljøet, medmindre andet aftales.
9.4 Problems, som Leverandøren ikke er ansvarlig for
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.5 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 Incidentet (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.
Service Desk
Supportansvaret omfatter at give adgang til en effektiv Service Desk. Leverandøren skal håndtere alle henvendelser og yde support til supportberettigede Brugere, KOMBIT, KOM- BITs repræsentanter samt Anvendersystemleverandører. De supportberettigede Brugere er navngivne superbrugere i kommunerne og hos kommunernes leverandører. Der henvises til bilag 2 afsnit xxx. Service Desken skal for alle henvendelser sikre opfølgning over for den person, der har henvendt 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
• Løbende holde Brugere informeret om status på ikke-afsluttede henvendelser ved hjælp af telefon, SMS, mail og/eller hjemmeside.
• 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 Desken
• Oprette, nedlægge og administrere Brugere
• 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, f.eks. for Fejl
ved Infrastruktur og Programmel leveret af Leverandøren. Denne type opgaver vareta- ges 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øren skal levere den fornødne support til Anvendersystemleverandørers opkobling og vedligeholdelse af Eksterne Snitflader.
Telefon | ||
I hele måleperioden | [Tilbudsgiver udfylder] | Tilbudsgiver udfylder] |
Tabel 10: 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 et 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 7, punkt 8 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 og/eller login til IT Service Management systemet. Efter indrapportering skal IT Service Ma- nagement systemet returnere bekræftelse med angivelse af unikt sags id. Supportberettigede Brugere skal kunne se og tilgå egne indrapporterede Incidents og Service Requests, såvel som ved søgning på sags id for Incidents og Service Requests indrapporteret af andre Bru- gere indenfor samme respektive administrative enhed. Det skal være muligt for KOMBIT eller dennes repræsentant at følge med i åbne sager (eksempelvis Incidents, Service Requests og Changes) ved hjæp af filtrering i IT Service Management systemet.
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.
Leverandøren skal på anmodning fra KOMBIT levere udtræk fra IT Service Management sy- stemet ud fra parametre angivet af KOMBIT. Udtrækkene kan f.eks. omfatte oversigt over In- cidents, Problems, Service Requests og Changes. Udtrækkene skal leveres til KOMBIT i et excel format senest 2 Arbejdsdage regnet fra KOMBITs anmodning.
Endvidere skal Leverandøren på anmodning fra KOMBIT levere udtræk af f.eks. oversigt over alarmer, alarmpunkter, svartidsmålinger, stikprøvemålinger, kontrolmålinger samt drifts- effektivitetsmålinger. Udtrækkene skal bearbejdes af Leverandøren til et maskinlæsbart for- mat, f.eks. CSV eller Excel, ud fra parametre angivet af KOMBIT. Udtrækkene skal leveres til KOMBIT senest 2 Arbejdsdage regnet fra KOMBITs anmodning.
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 f.eks. 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 7.9
o Ved prioritet A og B Incidents skal kritiske forhold om Incidentet formidles, sammen med tydelig angivelse af Incident start og tidspunkt for seneste opda- tering af status for Incidentet, samt når løst med løsningstidspunkt
• 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 (f.eks. med angivelse af release og dato, hvor Fejl 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 af Syste- met 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, f.eks. betingelser for an- vendelse af Service Desk
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
Leverandøren skal på KOMBITs anmodning give adgang til alle informationer om alle regi- strerede Incidents, Problems og Service Requests, senest 3 Arbejdsdage efter anmodning herom.
Servicemålene for Service Desk er beskrevet i Tabel 11 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 op- kald | Leverandørens Service Desk skal have følgende åbningstider: For telefonhenvendelser: 08 til 16 på Arbejdsdage For henvendelser via mail og webformular: Hele må- leperioden. | Måles og dokumente- res af Leverandøren. |
Servicemål for Service Desk | |||
Område | Definition | Servicemål | Måling |
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, skal modtage en per- sonlig reaktion på hen- vendelsen inden for 3 ti- mer – enten med løsning eller med besked på, hvordan og hvornår hen- vendelsen vil blive hånd- teret. Servicemålet gæl- der kun i hele måleperio- den. | 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 ydes af Service Desk overfor den person, der henvender sig. F.eks. password re- set. | 65 % af alle henvendelser opgjort for en kalender- måned af gangen skal være afsluttet ved første henvendelse i Service Desk. | Dokumenteres i Leve- randørens IT Service Management system. |
Tabel 11: 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 12: Option på udvidelse af Service Deskens åbningstid
10.5 Dokumentation af henvendelser til Service Desk
Generelt
Leverandøren skal månedligt og i øvrigt på KOMBITs anfordring levere nedenstående opgø- relser som dokumentation af henvendelser til Service Desk.
Som del af driftsrapporten, jf. bilag 7.2.G, skal Leverandøren levere en opgørelse (opgørelse 1) indeholdende statistik samt en opgørelse af periodens henvendelser. Opgørelse 1 skal le- veres i et maskinlæsbart format, samt omfatte følgende information for hver henvendelse:
• Dato
• Klokkeslæt
• Sags id
• Brugerens navn
• Brugerens organisation
• Brugerkategori, dvs. om personen, der henvender sig, er Primære Bruger, Sekundær Bruger, Anvendersystemleverandør, KOMBIT o.lign.
• Henvendelsesform (telefon, mail, web eller andet)
• Henvendelseskategori (Incident eller Service Request, herunder type)
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. Ved bestilling af løbende ydelser (f.eks. bestilling af ekstraordinær Ser- vice Desk-ydelser efter Overtagelsesdagen) er reaktionstiden dog tiden, der må gå fra bestil- ling, til Leverandøren skal have påbegyndt håndtering af bestillingen.
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. Ved bestil- ling af løbende ydelser (f.eks. bestilling af ekstraordinær Service Desk-ydelser efter Overta- gelsesdagen) er løsningstiden dog tiden, der må gå fra bestilling, til Leverandøren skal have påbegyndt levering af Service Requesten 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.1– 0 som Service Requests. Standardydelserne kan bestilles af KOMBIT et ubegrænset antal gange.
Leverandøren vil modtage en engangsbetaling, som er den fulde betaling for standardydel- serne beskrevet i punkt 11.2.1, 11.2.4, 11.2.5 og 0, idet der dog også til standardydelsen un- der punkt 11.2.2 og 11.2.3 kan kræves løbende betaling, hvis Leverandøren har angivet en pris herfor i bilag 7.2.B.
Service Request | 3402 type 2 revisionserklæring |
Kort beskrivelse | Leverandøren skal udarbejde en ISAE 3402 type 2 erklæring efter øn- |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2.B |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 90 dage |
11.2.2 Service Desk-ydelser før Overtagelsesdagen
Service Request | Service Desk-ydelser før Overtagelsesdagen |
Kort beskrivelse | delser om support til Service Desk i bilag 7.2.B. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2.B |
Servicemål | • Reaktionstid: 2 Arbejdsdage • Løsningstid: 90 Dage |
11.2.3 Ekstraordinær Service Desk-ydelser efter Overtagelsesdagen
Service Request | Ekstraordinær Service Desk-ydelser efter Overtagelsesdagen |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse i tillæg til Service Desk-ydelserne beskrevet i punkt 10 levere ekstraordinær Ser- vice Desk-ydelser, som indkluderer en øget bemanding med 50 %, samt en udvidelse af Service Deskens åbningstid til 24/7. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2.B |
Servicemål | • Reaktionstid: 2 Arbejdsdage • Løsningstid: 60 Dage |
11.2.4 Opsæt Integration til andet system
Service Request | Opsæt Integration til andet system |
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 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 |
11.2.6 Standardudtræk til Statens Arkiver
Service Request | Standardudtræk til Statens Arkiver |
Kort beskrivelse | Udtrækket til Statens Arkiver dannes ud fra en backup fra et årsskifte og afleveres i et format beskrevet og godkendt af Statens Arkiver. Ud- over udtrækket leveres den til arkiv-versionen såkaldte context-doku- mentation, det vil bl.a. sige lovgrundlag og aftalegrundlag med Statens Arkiver. Se endvidere bilag 2.1, afsnit 6.4.4. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2.B |
Servicemål | • Reaktionstid: 2 Arbejdsdage • Løsningstid: Skal leveres til Statens Arkiver senest 20 Arbejds- dage efter bestilling |
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
Servicemål for drift
[Punkt 13 med underpunkter udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
Leverandørens driftsydelser består overordnet af 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 0.
13.1 Servicemål for Applikationsdrift
Nedenfor angives først Servicemål til driftseffektivitet, dernæst måling af driftseffektivitet.
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.
Servicemålene for driftseffektiviteten af Systemet i Produktionsmiljøet er 99,5 Servicemålene for driftseffektiviteten af Systemet i Præproduktionsmiljøet er 95 ,0 % Servicemålene for driftseffektiviteten af Systemet i det Eksterne Testmiljø er 98,0 %
Applikationsdrift Servicemål for driftsef- fektivitet for Systemet per miljø | Måleperiode 1 |
Produktionsmiljøet | 99,5 % |
Præproduktionsmiljøet | 95,0 % |
Eksternt Testmiljø | 98,0 % |
Tabel 13 Oversigt over Servicemål for Applikationsdrift
13.1.2 Måling af driftseffektivitet for Applikationsdrift
Driftseffektiviteten måles for Systemet som helhed for henholdsvis Produktionsmiljø, Præpro- duktionsmiljø og Eksternt Testmiljø, 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 7.3.Tidsrum, hvor der er prioritet A Incidents eller prioritet B Incidents fragår således i Tilgængelig Driftstid. Dog bemærkes det, at tidsrum med prioritet A eller B Incidents som følge af for lange svartider ikke fragår i Tilgængelig Driftstid, jf. punkt 14.3.5 og 14.4.5. Tids- rum med for lange svartider fragår i stedet i Tilgængelig Driftstid i overensstemmelse med det i punkt 14.3.6 og 14.4.6 anførte. Herudover fragår tidsrum i Tilgængelig Driftstid, hvor Le- verandørens forhold indebærer en unødig forhaling af løsningen på et Incident, hvor Leve- randøren ikke eller kun delvis er ansvarlig for årsagen, jf. herunder punkt 7.7.3.
Der skal ved enhver driftsforstyrrelse som følge af prioritet A Incidents eller prioritet B Inci- dents fratrækkes minimum 5 minutter i Tilgængelig Driftstid, idet al yderligere driftsforstyr- relse 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), eller udefra kom- mende 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 7.6. For så vidt angå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 Incidentet, og indtil Leverandø- 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.
Eksempel 1:
En driftsforstyrrelse forårsaget af et 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 et 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 tn 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 et 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.
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 og opgøres særskilt for henholdsvis a) Måleperiode 1 og b) Målepe- riode 2.
13.2 Servicemål for Infrastrukturdrift
Nedenfor angives først Servicemål til driftseffektivitet, dernæst måling af driftseffektivitet.
13.2.1 Servicemål for driftseffektivitet for Infrastrukturdrift
Servicemålene for Produktionsmiljøets driftseffektivitet er 99,9 % i både Måleperiode 1 og Måleperiode 2.
Servicemålene for driftseffektivitet af Præproduktionsmiljø er 95,0 % i både Måleperiode 1 og Måleperiode 2.
Servicemålene for driftseffektivitet af det Eksterne Testmiljø er 98,0 % i Måleperiode 1 samt 95,0 % i Måleperiode 2.
Infrastrukturdrift Servicemål for driftseffektivitet per miljø | Måleperiode 1 |
Produktionsmiljøet | 99,5 % |
Præproduktionsmiljøet | 95,0 % |
Eksternt Testmiljø | 98,0 % |
Tabel 14 Servicemål for driftseffektivitet for Infrastrukturdrift
13.2.2 Måling af driftseffektivitet for Infrastrukturdrift
Driftseffektiviteten måles for Systemet som helhed for henholdsvis Produktionsmiljø, Præpro- duktionsmiljø og Eksternt Testmiljø, 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 7.3. 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å et Incident, jf. punkt 7.7.3, hvor Leve- randø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 drift safvikling er genetableret i form af, at de(n) pågældende Incident(s) er løst, jf. punkt 7.6. For så vidt angå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 Incidentet, og indtil Leverandø- 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.
Såfremt Systemet i Produktionsmiljøet, forud for indtræden af en Prioritet A eller Prioritet B Incident, har befundet sig i en ikke-redundant tilstand, beregnes Incidentstart (og dermed driftsforstyrrelsens start) fra det tidspunkt, hvor den ikke-redundante tilstand opstod, selvom driftsforstyrrelsen først opstod senere. En ikke-redundant tilstand betyder en tilstand, hvor ét produktionssite har været utilgængeligt, eller hvor enkeltkomponenter i Systemet har været fejlbehæftet, således at der har optrådt et single-point-of-failure i Systemet i Produktionsmil- jøet.
Den "Aftalte Driftstid" er hele Måleperioden.
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 ti l 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.
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åling for Produktionsmiljøet:
(Opgjort driftseffektivitet for Applikationsdrift i henhold til punkt 13.1.2 i % + opgjort driftsef- fektivitet for Infrastrukturdrift i henhold til punkt 13.2.2 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 og Måleperiode 2.
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 7.3. 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 Infrastrukturdrift
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 driftseffektivitet for Sy- stemet per miljø | Måleperioden |
Produktionsmiljøet | 99,5 % |
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åleperioden |
Produktionsmiljøet | 99,5 % |
Præproduktionsmiljøet | 95,0 % |
Eksternt Testmiljø | 98,0 % |
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 identificere, hvor eventuelle lange svartider opstår ved eksekveringen af funktionalitet i Systemet, eller hvor eventuelle lange svartider opstår ved udførelsen af automatiserede funktioner i Systemet.
Leverandøren skal gennem probemålinger og/eller svartidsmålinger kunne redegøre for den brugeroplevede svartid, således det giver et klart billede af, hvordan Systemet fungerer set fra Brugernes synsvinkel.
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 14.4.5.
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 14.4.2).
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 14.4.
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
• Beregning af tidsrum med driftsforstyrrelser pga. lange svartider (baseres på stikprø- vemålinger), jf. punkt 14.3.6 og 14.4.6
• Svartidstest ifm. ændringer på Systemet, Prøver mm. (baseres på kontrolmåling), jf. punkt 14.5.
14.2 Modregning af svartid uden for 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 14.4.4.
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 7, 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 f.eks. en søgning eller opdate- ring af en formular.
Ved svartiden for en transaktion i Systemets brugergrænseflade forstås tidsintervallet fra Brugeren sender sin kommando, til resultatet er synligt for Brugeren, 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
Det er KOMBIT, som i samarbejde med Leverandøren, fastlægger kategoriseringen af trans- aktioner. I tilfælde af uenighed er det KOMBIT, som bestemmer kategorien.
14.3.3 Måling af svartider i brugergrænsefladen
For hver transaktionskategori (jf. punkt 14.3.2) aftales et antal ”Målepunkter” (op til tre Måle- punkter 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 transaktionskategori skal Leverandøren (jf. punkt 2.3) med maksimalt 5 minutters interval udføre stikprøvemålinger af svartider i Systemets brugergrænseflader, dvs. at der mindst hvert 5. minut foretages stikprøvemålinger på de aftalte målepunkter for de tre kate- gorier samtidigt. En fuldstændig opgørelse over stikprøvemålingerne rapporteres på måned- lig 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).
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.5.
Tabel 15 nedenfor angiver de Ønskede Svartider og Maksimale Svartider for hver transakti- onskategori samt eksempler på transaktioner i hver kategori. Inddeling i transaktionskategori vil blive startet op som aktivitet i Afklaringsfasen og skal være afsluttet inden Overtagelses- prøven.
Ønskede og Maksimale Svartider for hver transaktionskategori i Systemet | |||
Transaktionens kategori | Ønskede Svartider (sekunder) | Maksimale Svartider (sekunder) | Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1 |
1 | 1 | 2 | Eksempler på use cases: UC-3, handling 1, opret nyt dokument UC-3, handling 1, vis besked UC-13, handling 1a, opret og rediger begi- venhed |
2 | 2 | 3 | Eksemple på use cases nr: UC-02, trin 1, opret og send besked |
3 | 4 | 6 | Eksempler på use cases nr: UC-22, trin 2 UC-Publicer opslag, trin 9 |
Tabel 15: Ønskede og Maksimale Svartider for hver transaktionskategori i Systemet
14.3.5 Incident-oprettelse ved lange svartider i Systemets brugergrænseflade
Dette afsnit beskriver, hvornår der skal oprettes et 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 et Incident, idet følgende gælder:
Der skal oprettes et Incident med prioritet A, såfremt Maksimale Svartider overskrides flere gange i en 60 minutters periode.
Der skal oprettes et 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 7.7, samt Problem håndtering, afledte RCA mm.
Eksempel:
En stikprøvemåling af svartiden for en kategori 1 transaktion kl 13:04 overstiger den Øn- skede Svartid på 1 sekund, og en stikprøvemåling kl 13.19 af en kategori 2 transaktion viser overskridelse af den Maksimale Svartid på 3 sekunder. Der skal oprettes et 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 7, og ikke med de undtagelser beskrevet under dette punkt 14.3.5.
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 Maksimal Svartid, 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åleperio- den (svarende til en omtrentlig omregning af Servicemålet om overholdelse af Maksi- male 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 Xxxxxxx, 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åleperioden 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:
14.3.7
Parterne har aftalt følgende antal Målepunkter for transaktionskategorierne: kategori 1 er aftalt 2 nærmere angivne Målepunkter, kategori 2 er aftalt 3 nærmere angivne Målepunk- ter, og kategori 3 er aftalt 3 nærmere 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 Maksimal Svartid. 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 Svartider for Servicetransaktioner i Eksterne Snitflader
14.4.1 Servicetransaktioner og Servicetransaktioners svartider
Systemets Eksterne Snitflader udstilles af en række services i Systemet. Hver Ekstern Snit- flade har et antal snitfladeoperationer, som kan tilgås og aktiveres af Anvendersystemer.
En Servicetransaktion betyder andre it-systemers anvendelse af Systemets Eksterne Snitfla- der ved fremsendelse eller modtagelse af én samlet forespørgsel/opdatering.
Ved svartiden for en Servicetransaktion forstås tidsintervallet fra, at Systemet modtager en besked fra et Anvendersystem i en Ekstern Snitflade, til behandlingen af beskeden i Syste- met er fuldt afsluttet og et eventuelt svar til relevant Anvendersystem er afsendt. F.eks. vil Systemets modtagelse af en besked fra et Anvendersystem og Systemets efterfølgende ek- sekvering af de af Anvendersystemet kaldte snitfladeoperationer være en Servicetransaktion.
Såfremt Systemet indeholder automatiserede funktioner, som Systemet selv eksekverer, op- fattes disse også som Servicetransaktioner i Eksterne Snitflader mht. svartidskravene under punkt 14.4 og underpunkter, og måles og opgøres i overensstemmelse hermed.
Ved eksekvering af automatiserede funktioner i Systemet forstås svartiden for en Service- transaktion, som tidsintervallet fra den automatiserede funktion påbegyndes, til den automati- serede funktion er fuldt afsluttet, og Systemet er fuldt opdateret.
14.4.2 Kategorisering af Servicetransaktioner
Det er KOMBIT, som i samarbejde med Leverandøren, fastlægger kategoriseringen af Ser- vicetransaktioner. I tilfælde af uenighed er det KOMBIT, som bestemmer kategorien.
14.4.3 Måling af svartider for Servicetransaktioner
For hver servicetransaktionskategori (jf. punkt 14.4.2) aftales et antal ”Målepunkter” (op til tre Målepunkter pr. kategori), som tilsammen udgør et repræsentativt billede af Systemets sam- lede 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 servicetransaktionskategori skal Leverandøren indenfor måleperioden (jf. punkt 2.3) med maksimalt 5 minutters interval udføre stikprøvemålinger af svartider i Systemet, dvs. at der mindst hvert 5. minut foretages stikprøvemålinger på de aftalte målepunkter for de tre ka- tegorier 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.4.6. En Stikprøvepakke kan således indeholde op til 9 samtidige stikprøvemålin- ger (op til tre Målepunkter pr. kategori).
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 Servicetransaktioner på Systemet. Detail-logs kan anvendes af Leverandø- ren til afklaring i tilfælde af eksempelvis Incidents eller ved udfald af stikprøvemålinger, jf. punkt 14.4.6. Disse logs skal fremsendes til KOMBIT som en del af den månedlige driftsrap- portering. Detail-logs skal leveres i et format, der er læsbart på en almindelig kontor-PC.
14.4.4 Servicemål for svartider for Servicetransaktioner
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.4.6, hvor de omregnes til et antal acceptable stikprøveoverskridelser, og ved Kon- trolmålinger, jf. punkt 14.5.
I Tabel 16 nedenfor er angivet de Ønskede Svartider og Maksimale Svartider for hver ser- vicetransaktionskategori samt eksempler på Servicetransaktioner i hver kategori. Inddeling af Servicetransaktioner i kategorier vil blive startet op som aktivitet i Afklaringsfasen og skal være afsluttet inden Overtagelsesprøven.
Ønskede og Maksimale Svartider for hver servicetransaktionskategori i Systemet | |||
Servicetransaktionens kategori | Ønskede Svartider (sekunder) | Maksimale Svartider (sekunder) | Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1 |
1 | 0,5 | 2 | Eksempler / Gælder for use case nr: |
2 | 2 | 3,5 | Eksempler / Gælder for use case nr: |
3 | 3 | 8 | Eksempler / Gælder for use case nr: |
Tabel 16: Ønskede og Maksimale Svartider for hver kategori af Servicetransaktioner i Syste- met
Såfremt en Servicetransaktion har et input eller et output, der overstiger 5 MB, øges Service- målene med 2 sekunder pr. MB, der overstiger 5 MB. Bemærk, at svartiden måles til det fulde output er fuldt eksekveret, eksempelvis til det fulde output er modtaget af Anvendersy- stemet, jf. også punkt 14.4.1.
14.4.5 Incident-oprettelse ved Servicetransaktioners lange svartider
Dette afsnit beskriver, hvornår der skal oprettes et Incident på grund af lange svartider for Servicetransaktioner i Eksterne Snitflader.
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 et Incident, idet følgende gælder:
Der skal oprettes et Incident med prioritet A, såfremt Maksimale Svartider overskrides flere gange i en 60 minutters periode.
Der skal oprettes et 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 7.7, samt Problem håndtering, afledte RCA mm.
Eksempel:
En stikprøvemåling af svartiden for en kategori 1 Servicetransaktion kl 10:55 overstiger den Ønskede Svartid på 0,5 sekund, og en stikprøvemåling kl 11.50 af en kategori 2 Ser- vicetransaktion viser overskridelse af den Maksimale Svartid på 3,5 sekunder. Der skal oprettes et Incident med prioritet B, da niveauet for Ønskede Svartider er brudt to gange indenfor 60 minutter.
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 7, og ikke med de undtagelser beskrevet under dette punkt 14.4.5.
14.4.6 Beregning af tidsrum med driftsforstyrrelser pga. Servicetransaktioners lange svartider
Manglende opfyldelse af Ønskede Svartider eller Maksimale Svartider, jf. punkt 14.4.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.4.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.4.3, hvor en eller flere stikprøvemålinger viser overskridelse af Maksimal Svartid, 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- oden (svarende til en omtrentlig omregning af Servicemålet om overholdelse af Mak- simale Svartider i 99,9 % af måleperioden, jf. punkt 14.4.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 Xxxxxxx, 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åleperioden (svarende til en omtrentlig omregning af Servicemålet om overholdelse af Ønskede Svartider i 98% af måleperioden, jf. punkt
14.4.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 servicetransaktionskategorierne: kate- gori 1 er aftalt 3 nærmere angivne Målepunkter, kategori 2 er aftalt 3 nærmere angivne Målepunkter, og kategori 3 er aftalt 3 nærmere angivne Målepunkter.
Leverandøren foretager stikprøvemålinger på de 9 aftalte Målepunkter samtidigt. Disse 9 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 12 Stikprøvepakker indeholder stikprøvemålinger med overskridelser, hvoraf mindst én overskridelse er en overskridelse af Maksimal Svartid. 25 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 (12-2) * 5 minutter
= 50 minutter.
Da antallet af Stikprøvepakker, der ikke overskrider Xxxxxxxx Xxxxxxx, men med overskri- delser af Ønsket Svartid, ikke overstiger de 40 acceptable, reduceres Tilgængelig Drifts- tid derfor ikke på baggrund heraf.
Den samlede tid, som fragår i Tilgængelig Driftstid, udgør derfor ( 50+0 minutter) 50 mi- nutter.
14.5 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 14.4.1) i Produktionsmiljøet som kon- trol, når konkrete forhold, eks. ved indrapportering af Incidents, indikerer, at svartiderne aktu- elt ikke opfyldes, men hvor de løbende stikprøvemålinger ikke giver fejlende udslag. Kontrol- må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 14.4.3).
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.5, 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 14.4.3) 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. automatiserede funktioner (”Summen af Servicetransaktions-målinger”), udgør tilsam- men 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 14.4.4.
For at en Kontrolmåling ikke fejler, skal Kontrolmålingen overholde alle fire Servicemål, jf. punkt 14.3.4 og 14.4.4, dvs. overholde 98% af Ønskede Svartider og 99,9% af Maksimale Svartider for alle målinger af transaktioner i brugergrænsefladen, samt overholde 98% af Øn- skede Svartider og 99,9% af Maksimale Svartider for alle målinger af Servicetransaktioner inkl. automatiserede 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.
Et 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 t ilsvarende Kontrolmåling er gennem- ført uden overskridelser af Servicemål.
14.6 Opgørelse af svartider samt tidsrum med driftsforstyrrelser for Afsendersystemer
Leverandøren skal løbende opgøre svartider samt tidsrum med driftsforstyrrelser for alle Af- sendersystemer. Såfremt KOMBIT stiller krav herom, skal Leverandøren stille denne infor- mation til rådighed på en hjemmeside og/eller log. Opgørelsen skal være tilstrækkelig deltal- jeret, således at det er muligt at følge udviklingen i svartider på timebasis med opgørelse af gennemsnit samt maksimale svartider.
KAPITEL II SERVICE TRANSITION
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 via Patch Management, jf. punkt 19, og Change Management, jf. punkt 16.
• Test i forbindelse med opdatering af Systemet eller Infrastrukturen, jf. punkt 17.
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.
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 KOM- BITs organisation
• Dokumentation af alle Changes, jf. punkt 16.3
• Forberedelse til samt gennemførelse af RfC’ens behandling i Change Ad- visory 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, Anvendersystemleverandører eller Tredjepartsprogrammelleverandører.
• Løbende orientering af indberetteren af RfC, om status, herunder i forbin- delse 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 afta- ler herom
• Sikre at relevante tests gennemføres inden implementering samt gen- nemførsel af efterfølgende funktionsafprøvning til sikring af den fulde funktionalitet af Systemet.
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 beskrivelse af, hvilke tests som foretages
• 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, eller hvad der ligger til grund for, at det ikke vil være muligt at rulle tilbage til udgangspunktet
• Eventuelle konsekvenser for Dokumentation, herunder installationsvejledninger, drifts- vejledninger mv.
• Eventuelle konsekvenser for Leverandørens Ydelser og overholdelse af Servicemål
• Eventuelle konsekvenser for supportsamarbejdet
Validation og test
Leverandøren skal sikre, at der i forbindelse med alle nye Versioner, jf. punkt 18, samt øvrige Changes, testes behørigt i overensstemmelse 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 7, 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 f.eks. 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 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.
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
• 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 Systemet og Driftsmiljøet med nye Versioner af Program- mel/programmel
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, herunder om væsentlige ændringer i forhold til tidligere Versioner, når sådanne fore- ligger.
Leverandøren skal i forbindelse med nye Versioner orientere KOMBIT om konsekvenserne ved at installere en ny Version, og ved ikke at installere en ny Version, herunder Leverandø- rens overholdelse af Systemets Servicemål.
Hvis KOMBIT ønsker den nye Version installeret, forestår Leverandøren sådan installation 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.
[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 nye Versioner af Tredjepartsprogrammel
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.
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 17:
Mindre opdateringer: | |
Servicevindue: Varighed: Varsling: | 1 gang om ugen i tidsrummet lørdag kl. 01.00- 02.00 CET 1 time 1 uge |
Større og kritiske opdateringer: | |
Servicevindue: Varighed: Varsling: | Op til 1 gang pr. måned i tidsrummet lørdag kl. 01.00 til lørdag kl. 04.00 CET 3 timer 1 måned |
Omlægning af miljøer, arkitektur og services: | |
Servicevindue: Varighed: Varsling: | 1 gang pr. kvartal i tidsrummet lørdag kl. 00.00 til lørdag kl. 08.00 CET 8 timer 2 måneder |
Leverandøren kan ikke fastlægge servicevinduer i perioden 2 Arbejdsdage før og efter et må- nedsskift, 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.
Patch Management
Patch Management processen gør det muligt for Leverandøren at levere opdateringer af Pro- grammel 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 Tredjepartspro- grammel.
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 KOMBIT kræver.
• Leverandøren skal sikre sig at leve fuldt op til de i Driftskontraktens punkt 13.4 nævnte lovgivningsmæssige krav.
• Leverandøren skal uden unødigt ophold informere KOMBITs driftschef eller dennes repræsentant om identificerede sikkerhedsrisici, der ikke kan rettes i Infrastrukturen.
• Leverandøren skal sikre og vedligeholde en service management procedure, der in- kluderer en patchproces, 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 angivne værdier.
• Patches testes før installation, og det skal sikres, at servere fungerer korrekt efter op- datering.
• Dokumentation, jf. bilag 4 og bilag 7.2.F, indeholdende overblik over installerede Pat- ches 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 Mana- gement processen.
Det er KOMBITs ansvar at sikre det nødvendige aftalegrundlag for, at Tredjepartsprogram- melleverandø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
[Punkt 19.1 med underpunkter udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbe- hold overfor.]
Nedenstående tabel beskriver installationsfristen, gældende for Patch af Programmel i Syste- met og programmel i Driftsmiljøet, herunder infrastrukturkomponenter. Disse frister tilside- sætter ikke Servicemål for Incident Management i tilfælde af driftsforstyrrelser.
Patchtype | Installations- frist | Opfyldelsesgrad (%) |
Kritisk Sikkerhedsmæssig Patch: Eksempelvis: Sårbarheder, hvis udnyttelse kan medføre kompromittering af fortrolighed, integritet eller tilgængeligheden af brugerdata i forbindelse med eks. persondataloven, eller eksekvering af kode uden advarsler eller prompter | Hurtigst muligt, dog senest in- den 3 timer | 100 |
Vigtig Sikkerhedsmæssig Patch: Eksempelvis: Sårbarheder, hvis udnyttelse kan medføre kompromittering af fortrolighed, integritet eller tilgængeligheden af brugerdata, eller system- ressourser | 10 Arbejdsdage | 100 |
Moderat Patch: Eksempelvis: Patches, der har til formål at sikre, at sårbarheder afbødes i betydelig grad, således at der ikke kan skabes prioritet A eller B Incidents. | 20 Arbejdsdage | 100 |
Øvrig Patch: Patches, der ikke dækkes af øvrige patchtyper | Efter aftale – dog højst 90 Dage | 100 |
Tabel 18: Servicemål for Patch Management
Installationsfristen beskriver den tid, der maksimalt må gå, før relevante Patches er installe- ret, og gælder fra det tidspunkt, hvor en Patch er frigivet.
Der er efter forudgående skriftlig aftale med KOMBIT mulighed for at nedgradere patchtypen, hvis patchtypen vurderes som mindre betydende. KOMBIT kan afvise et ønske fra Leveran- døren om at nedgradere patchtypen.
Leverandøren skal ved konstatering af patchtypen Kritisk Sikkerhedsmæssig Patch, 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øs- ning. Hvis der ikke kan opnås kontakt til KOMBITs driftschef, skal Leverandøren uden yderli- gere ophold udføre de nødvendige tiltag for at imødegå den sikkerhedsmæssige risiko.
Ved uenighed om kategorisering af patchtype afgøres tvisten i overensstemmelse med Drifts- kontraktens punkt 33.2.
19.1.1 Manglende opfyldelse af servicemål
Såfremt Leverandøren ikke overholder Servicemålet for patchtypen Kritisk Sikkerhedsmæs- sig Patch og patchtypen Vigtig Sikkerhedsmæssig Patch, skal forholdet anses og behandles som en prioritet A Incident, jf. punkt 7.3 og 7.7.
Såfremt Leverandøren ikke er i stand til at opfylde Servicemålet for patchtypen Kritisk Sikker- hedsmæssig Patch, skal Leverandøren straks fremsende forslag til relevant Omgåelse af In- cident til KOMBIT med henblik på godkendelse.
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.
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 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 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 III SERVICE DESIGN
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.
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, indet 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.
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.
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
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 90 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 aftalt mel- lem Parterne inden gennemførelsen.
Scope for den årlige Disaster Recovery test udarbejdes inden testen i samarbejde med KOM- BIT. Som udgangspunkt gennemføres testen i Produktionsmiljøet, men KOMBIT kan vælge at acceptere, at testen gennemføres uden reel påvirkning af Driftsmiljøet.
KOMBIT kan kræve, at Disaster Recovery testen udføres samtidig og integreret med tilsva- rende 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 Disa- ster Recovery testen med Anvendersystemleverandørers tilsvarende planer 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 genetab- lering vil medføre en normal driftssituation for Systemet og de involverede Anvendersyste- mer.
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 inden for 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 redundant setup i Produktionsmiljøet
Generelt
Leverandøren skal én gang hvert halvår, regnet fra godkendt Driftsprøve, gennemføre en af- prøvning af redundante komponenter i Produktionsmiljøet ved at deaktivere en redundant komponent og verificere, at Anvendernes adgang til Systemet er upåvirket og uden datatab. Efterfølgende genaktiveres den redundante komponent og efterfølgende konstateres, at An- venderne fordeles mellem komponenterne som forventet. Det aftales mellem Parterne fra gang til gang forud for afprøvning, hvilke redundante komponenter, som skal afprøves, såle- des at det altid er de mest relevante komponenter som afprøves. Afprøvningen skal doku- menteres overfor KOMBIT og i øvrigt gennemføres i et af de fastlagte servicevinduer.
Hvis Leverandøren tilbyder at aktivt-passivt setup
Leverandøren skal senest 30 Dage efter godkendt Driftsprøve samt efterfølgende én gang hvert år gennemføre en afprøvning af det redundante setup i Produktionsmiljøet, således at driften flyttes fra det primære setup til det redundante sekundære setup. Overflytningen skal påbegyndes i et af de fastlagte servicevinduer, og løsningen 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. Afprøvningen skal dokumenteres overfor KOMBIT.
Hvis Leverandøren tilbyder et aktivt-aktivt setup
Leverandøren skal senest 30 Dage efter godkendt Driftsprøve samt efterfølgende én gang hvert år gennemføre en afprøvning af det redundante setup i Produktionsmiljøet. Det aftales mellem Parterne fra gang til gang forud for afprøvning, hvilke områder i løsningen som skal afprøves, således at det altid er de mest relevante områder som afprøves. Det vil f.eks. være relevant at afprøve løsningens robusthed, hvis front-end serverne i et datacenter helt eller
delvist holder op med at svare, eller hvis load-balanceren retter alle forespørgsler mod kun et datacenter. Afprøvningen skal påbegyndes i et af de fastlagte servicevinduer, og løsningen skal være fuldt fungerende i den aftalte afprøvningsperiode, inden der vendes tilbage til nor- mal drift i et af de fastlagte servicevinduer. Afprøvningen skal dokumenteres overfor KOM- BIT.
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
• 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, kvalitetssikringsme- toder 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 initiale 4-årige løbetid at kræve, at der gennemføres en ekstern audit specifikt af Ydelserne til KOMBIT, herunder KOMBITs sikkerhedspolitik, ISO27001, Leverandørens og Underleverandørers overholdelse af kvalitetssikringsmetoder, driftsprocedurer, Servicemål, samt krav til Dokumentation, herun- der Driftshåndbogen, jf. bilag 7.2.F, mm. Auditten skal resultere i en ISAE 3402 type 2 erklæ- ring eller tilsvarende, 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.
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.
Plan for og test af Systemets overdragelse til Infrastrukturdrift
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.
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, e ks. 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 t il 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.
Plan for og test af Systemets overdragelse af Infrastrukturdrift og Applikati- onsdrift
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ø.
Overdragelsesplanen skal have en kvalitet og opdateres som beskrevet i Driftskontraktens punkt 30.
Overdragelsesplanen for Infrastrukturdrift og Applikationsdrift skal forelægges for KOMBIT ti l 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.
Deltagelse i overdragelse af Infrastrukturdrift og Applikationsdrift
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.