SOCIAL PENSION KOMMUNE
SOCIAL PENSION KOMMUNE
BILAG 7.1 YDELSER OG SERVICEMÅL
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 ikke udfyldes af Tilbudsgiver, idet Tilbudsgivers besvarelse af bilaget skal ske ved at udfylde bilag 7.1.B i henhold til instruktionerne angivet i bilag 7.1.B.
Tilbudsgivers besvarelse skal indsættes med tydelig markering, f.eks. med farvet skrifttype, så det er klart for KOMBIT, hvilke dele af bilaget der er besvaret af Tilbudsgiver. Anvendelse af ændringsmarkering er reserveret til Tilbudsgivers eventuelle forbehold.
Tilbudsgivers eventuelle forbehold til bilag 7.1 anføres i forbeholdslisten og skrives ind med ændringsmarkering i selve bilaget i overensstemmelse med udbudsbetingelserne.
Det bemærkes, at Kontrakten og Driftskontraktens bilag 7 uden bilag udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor, jf. udbudsbetingelserne. Tilbudsgiver skal derfor sikre, at eventuelle forbehold til bilag 7.1 ikke udgør et forbehold over for disse dokumenter.
Det bemærkes endvidere, at følgende dele af bilag 7.1 udgør minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor:
• Punkt 7.7 med underpunkter
• Punkt 12 med underpunkter
• Punkt 13 med underpunkter
• Punkt 18.1 med underpunkter
Om betydningen og vurderingen af Tilbudsgivers besvarelse af instrukser og eventuelle forbehold til bilaget henvises til udbudsbetingelserne.
BILAGETS ÆNDRINGSLOG
Versions- nummer | Ikrafttrædelsesdato | Emne |
1.0 | Udbudsdato indsættes | Oprindeligt offentliggjort dokument |
INDHOLDSFORTEGNELSE
2.2 Generelt om Leverandørens Ydelser 11
2.4 Kritiske Servicemål og Kritiske ikke-månedlige Servicemål 12
2.4.2 Kritiske ikke-månedlige Servicemål 12
KAPITEL II SERVICE OPERATION 14
3 INTRODUKTION TIL SERVICE OPERATION 14
4 MONITORERING OG EVENT MANAGEMENT 14
5 DRIFTSAFVIKLING AF BATCHKØRSLER 16
5.1 Servicemål for Batchkørsler 16
7.1 Generelle krav til Leverandørens Incident Management 18
7.2 Indrapportering af information om Incidents 19
7.3 Prioritering af Incidents 20
7.4 Kategorisering af Integrationer til incidentprioritering 22
7.5 Kategorisering af Batchkørsler til Incidentprioritering 24
7.6.3 Leverandørens generelle ansvar 26
7.7 Servicemål for Incident Management 27
7.8 Kontaktperson til KOMBITs rapportering af Incidents 30
7.9 Eskalering til KOMBIT samt orientering om Incidents til Brugere og øvrige Interessenter 31
7.9.1 Servicemål for orientering af KOMBIT og Interessenter 31
7.10 Afslutning på Incident Management processen 32
8.2 Ydelser under Problem Management 34
8.3 Prioritering af Problems 35
8.4 Problems, som Leverandøren er ansvarlig for 36
8.4.1 Servicemål for afhjælpning af Problems 36
8.5 Problems, som Leverandøren ikke er ansvarlig for 36
8.6 Servicemål for Root Cause Analyser 37
9.2 IT Service Management system 39
9.4 Servicemål for Service Desk 41
9.5 Dokumentation af henvendelser til Service Desk 43
10.1 Indrapportering af information om Service Requests 44
10.2 Forhåndsdefinerede Service Requests 45
10.2.1Udarbejdelse af systemspecifik revisionserklæring 45
10.2.2Service Desk-ydelser før Overtagelsesdagen for Basisløsningen 45
10.2.3Opsæt Integration til andet system 46
10.2.4Supplerende Testmiljø, jf bilag 7.3 punkt 5.6 46
10.2.5Ekstra testmiljø, jf bilag 7.3 punkt 5.7 47
10.2.6Udarbejdelse af overdragelsesplan for Infrastrukturdrift 48
10.2.7Udarbejdelse af overdragelsesplan for Infrastrukturdrift og Applikationsdrift 48
10.2.10 Centraladministration 49
10.2.11 Konfigurationsændringer 49
10.2.13 Opdatering af skabelon 49
10.2.14 Standard testdatasæt 50
10.3 Servicemål for Service Requests 50
12.1 Servicemål for Applikationsdrift 51
12.1.1Servicemål for driftseffektivitet for Applikationsdrift 51
12.1.2Måling af driftseffektivitet for Applikationsdrift 52
12.2 Servicemål for Infrastrukturdrift 53
12.2.1Servicemål for driftseffektivitet for Infrastrukturdrift 53
12.2.2Måling af driftseffektivitet for Infrastrukturdrift 54
12.3 Kombineret Tilgængeligheds Servicemål 55
12.4 Systemets brugeroplevede driftseffektivitet 56
13.2 Oprettelse af Incidents 57
13.5 Svartider for transaktioner i brugergrænsefladen 59
13.5.1Transaktioner og transaktioners svartider 59
13.5.2Servicemål for svartider i brugergrænsefladen 59
13.6 Svartider for automatiserede Servicetransaktioner og Eksterne Snitflader 60
13.6.1Servicetransaktioner og Servicetransaktioners svartider 60
13.6.2Servicemål for svartider for Servicetransaktioner 61
13.7 Opgørelse af målopfyldelse for svartid 62
13.7.2Beregning af målopfyldelse 62
13.7.3Reduktion af Tilgængelig Driftstid 63
13.8 Brugeroplevede svartider 65
KAPITEL III SERVICE TRANSITION 66
14 INTRODUKTION TIL SERVICE TRANSITION 66
15.1 Generelle krav til Change Management 66
15.1.1Procedure for behandling af Request for Changes 67
15.2 Servicemål for Change Management 69
15.3 Risikovurdering af RfC 70
17 RELEASE AND DEPLOYMENT MANAGEMENT 72
17.1 Vedligeholdelse af Systemet og Driftsmiljøet med nye Versioner af Programmel/programmel72
17.2 Vedligeholdelse af Systemet med nye Versioner af Tredjepartsprogrammel 74
17.3 Vedligeholdelse af Integrationer 74
17.4.1Servicemål for sletning af data 75
17.5 Servicevinduer til vedligeholdelse 75
17.6 Plan for nye Versioner 77
18.1 Servicemål for Patch Management 78
18.1.1Manglende opfyldelse af servicemål 79
19 ASSET- OG CONFIGURATION MANAGEMENT 79
21 INTRODUKTION TIL SERVICE DESIGN 81
24.1 Disaster Recovery plan 82
24.2 Disaster Recovery test 83
24.3 Disaster Recovery rapport 83
24.4 Afprøvning af redundant setup i Produktionsmiljøet 83
25 INFORMATION SECURITY MANAGEMENT 84
26 SUPPLIER MANAGEMENT OG BUSINESS RELATIONS 88
27 PLAN FOR OG TEST AF SYSTEMETS OVERDRAGELSE TIL INFRASTRUKTURDRIFT 88
28 DELTAGELSE I OVERDRAGELSE AF INFRASTRUKTURDRIFT 89
29 PLAN FOR OG TEST AF SYSTEMETS OVERDRAGELSE AF INFRASTRUKTUR- OG APPLIKATIONSDRIFT 89
30 DELTAGELSE I OVERDRAGELSE AF INFRASTRUKTUR- OG APPLIKATIONSDRIFT 90
KAPITEL I INDLEDNING
1 INDLEDNING
Nærværende bilag har til formål at beskrive krav til og Servicemål for Leverandørens drift og Ydelser relateret til Applikationsdrift, Applikationsvedligehold og Infrastrukturdrift, hvor Leverandøren har det samlede leveranceansvar for disse tre Ydelser.
Dette bilag er opdelt i fire kapitler startende med dette indledende KAPITEL I, der indeholder indledning og generelle bestemmelser for Leverandørens Ydelser.
KAPITEL II indeholder krav og Servicemål til Leverandørens driftsafvikling samt Ydelser under Service Operation.
KAPITEL III indeholder krav og Servicemål til Leverandørens Ydelser under Service Transition. KAPITEL IV indeholder krav og Servicemål til Leverandørens Ydelser under Service Design.
Det bemærkes, at bilag 7.1 har forrang frem for bilag 7.1.B, jf. Kontraktens punkt 57.2.
2 GENERELLE BESTEMMELSER
For Leverandørens Ydelser gælder generelt de i dette punkt 2 angivne bestemmelser og krav.
2.1 ITIL
Drift, vedligeholdelse og support skal håndteres i overensstemmelse med ITIL v3 (eller tilsvarende).
I Driftskontrakten anvendes de i nedenstående tabel anførte begreber fra ITIL v3 i overensstemmelse med disse begrebers overordnede forståelse i ITIL v3. Brugen af begreberne indebæ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 nærværende bilag 7.1 eller bilag
7.1.B (Specifikation af Ydelser).
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 mellem 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 |
ITIL begreb | Standard ITIL v3 Definition | Beskrivelse af afvigelse fra standard ITIL v3 definitionen |
Asset Management | Ja | |
Availability Management | Ja | |
Backup | Ja | |
Capacity Management | Ja | |
Change | Ja | |
Change Advisory Board (CAB) | Ja, men med afvigelse | CAB behandler RfC som en del af Change Management processen og er beskrevet i bilag 8. Change Management behandler 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 afvigelse | Change Management er den proces, som anvendes, når ændringer skal implementeres i Driftsmiljøet. Change Management i Driftskontrakten rådgiver om ændringer, samt godkender idriftsættelsen af RfC. Prioriteringer af ændringer til Systemet, udvikling af ændringer, test af ændringer og Dokumentation 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 afvigelse. | I Driftskontrakten benyttes ordet 1st Level Support i stedet for First-line Support |
ITIL begreb | Standard ITIL v3 Definition | Beskrivelse af afvigelse fra standard ITIL v3 definitionen |
Incident | Ja | |
Incident Management | Ja | |
Incident Record | Ja | |
Information Security Management | Ja | |
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 afvigelse. | I Driftskontrakten benyttes ordet 2nd Level Support tilsvarende Second-line Support. |
Security Incident | Ja | |
Service Design | Ja | |
Service Desk | Ja |
ITIL begreb | Standard ITIL v3 Definition | Beskrivelse af afvigelse fra standard ITIL v3 definitionen |
Service Operation | Ja | |
Service Request | Ja | |
Service Transition | Ja | |
Standard Change | Ja | |
Supplier Management og Business Relations | Ja | |
Third-line Support | Ja, men med afvigelse. | I Driftskontrakten benyttes ordet 3rd Level Support tilsvarende Third-line Support |
Workaround | Ja, men med afvigelse. | 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 Ydelserne 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 Tredjepartsprogrammel 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.1.
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 Tredjepartsprogrammelleverandø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 KOMBITs 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 et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
For Leverandørens Ydelser og Servicemål gælder følgende måleperioder.
• Måleperiode 1: Arbejdsdage kl. 08.00-16.00
• Måleperiode 2: Al tid uden for Måleperiode 1
Medmindre andet er angivet i dette bilag, i Driftskontrakten eller øvrige bilag hertil, gælder der samme krav og Servicemål indenfor de to måleperioder.
2.4 Kritiske Servicemål og Kritiske ikke-månedlige Servicemål
Der er blandt de i dette bilag 7.1 fastsatte Servicemål og Ydelser en række kritiske Servicemå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 opfyldelse af Driftskontrakten.
De Kritiske Servicemål og Kritiske ikke-månedlige Servicemål er angivet i henholdsvis punkt 2.4.1 og punkt 2.4.2.
Følgende Servicemål udgør Kritiske Servicemål og er af væsentlig betydning for KOMBIT, jf. også Driftskontraktens punkt 28:
• Hvert enkelt Servicemål for reaktionstider, løsningstider og eskaleringstider for prioritet A og B Incidents angivet under punkt 7.7.4
• Hvert enkelt Servicemål for orientering af KOMBIT og Interessenter om prioritet A og B Incidents angivet under punkt 7.9.1
• Hvert enkelt Servicemål for afhjælpning af prioritet A og B Problems angivet under punkt 8.4.1
• Hvert enkelt Servicemål for Root Cause Analyser for prioritet A og B Problems angivet under punkt 8.6
2.4.2 Kritiske ikke-månedlige Servicemål
Følgende Ydelser udgør Kritiske ikke-månedlige Servicemål og er af væsentlig betydning for KOMBIT, jf. også Driftskontraktens punkt 28:
• Restore test, som skal gennemføres en gang i kvartalet, jf. punkt 6.
• Disaster Recovery test rapport, som skal leveres senest 10 Arbejdsdage efter gennemført test, jf. punkt 24.3.
• Handlingsplanerne fra Disaster Recovery test rapport, som skal gennemføres indenfor 90 dage efter testens afslutning, jf. punkt 24.3.
• Levering af revisionserklæringer, som bl.a. skal ske senest hvert år, jf. punkt 25.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.
KAPITEL II SERVICE OPERATION
3 INTRODUKTION TIL SERVICE OPERATION
Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leverandø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 10
• Access Management, jf. punkt 11
• Servicemål for drift, jf. punkt 12
• Systemets svartider, jf. punkt 13
Leverandørens rapportering vedrørende driftssituationen, herunder Dokumentation for overholdelse af krav og Servicemål, er yderligere reguleret i bilag 7.5.
4 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 kapacitet mv. i Produktionsmiljøet, herunder CPU, RAM, lagerplads, netværk, serverprocesser mv. Monitoreringen skal tillige omfatte brugsmønstre, sammensætninger i transaktionsmiks og volumener, hvor væsentlige afvigelser fra normalbilledet skal udløse Events.
Leverandøren skal anvende proaktivt overvågnings- og analyseværktøj, som kan identificere og forudsige fejl og performance degraderinger i den fysiske og logiske infrastruktur med henblik på at forebygge Incidents.
Integrationer i Produktionsmiljøet skal overvåges, så vidt muligt ved overvågning af de faktiske servicekald. Hvis dette ikke er muligt, eller hvis der er meget få kald, skal overvågningen og målingen ske ved brug af kald til servicen med probe eller lignende.
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 Produktionsmiljø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 Produktionsmiljø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å Systemets hjemmeside, jf. punkt 9.3
• Gøre Monitorering og Event Management data tilgængelige for KOMBIT i maskinlæsbart format
4.1 Events
Leverandøren skal som en del af Leverandørens Event Management proces specificere metode 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 i Produktionsmiljøet, samt Produktionsmiljøet selv, 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 muligt at forebygge risikoen for Incidents.
Leverandøren skal sikre, at det er muligt for KOMBIT, eller en repræsentant for KOMBIT, at få fjernadgang til monitoreringsinformationen for den aktuelle driftssituation samt historiske driftsdata, herunder overblikket over Events.
Leverandøren skal sikre, at alle relevante Events registreres som Incidents, og at disse adresseres i henhold til gældende Servicemål, jf. punkt 7.
4.2 Logning
Leverandøren skal sikre, at der gennemføres en logning i overensstemmelse med bilag 2 og som lever op til best practice på området.
Logningen kan udover de i Kontrakten, herunder bilag 2 samt Driftskontrakten, nævnte logs, blandt andet være driftslogs som transaktionslogs, databaselogs, backuplogs, eventlogs 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 Integrationer mod Afsendersystemer.
Logningen skal ske på en måde, som sikrer, at logs kan anvendes i arbejdet med at analysere Events og Incidents samt andre hændelser og aktiviteter i forbindelse med driften. Log skal således forefindes i en form og med en værktøjsunderstøttelse, som tillader hurtig fejlsøgning og fremsøgning af informationer på tværs af komponenterne i Driftsmiljøet og Systemet. Logningen skal desuden foretages i et omfang, som understøtter revision og audit af Leverandøren og Ydelserne samt overholdelse af persondatalovgivningen.
Der skal etableres periodisk gennemgang af relevante logs med henblik på at supplere den automatiserede sikkerhedsmæssige overvågning af Systemet. Der skal oprettes Incidents på alle observationer, som under gennemgangen giver anledning til nærmere undersøgelser.
For at KOMBIT kan etablere sin egen detaljerede overvågning af Systems driftsafvikling, skal Leverandøren sikre, at det er muligt for KOMBIT, eller en repræsentant for KOMBIT, at tilgå live log data i maskinlæsbart format. Dette inkluderer også Leverandørens logdata i forbindelse med overvågning af Afsendersystemer. Logdata skal kunne hentes via en Integration.
5 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 Parterne har aftalt, jf. bilag 7.4.
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.4. 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 Driftskontraktens punkt 33.
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 gennemført korrekt og uden Fejl hurtigst muligt i tæt dialog og samarbejde med evt. involverede Anvendersystemleverandø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 prioriteringen 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 (Driftshåndbogen).
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 den enkelte Batchkørsel, fastlægges af KOMBIT i samarbejde med Leverandøren inden påbegyndelse af en Overtagelsesprøve og skal fremgå af Driftshåndbogen, jf. bilag 7.4.
6 BACKUP OG RESTORE
Leverandøren skal sikre, at Backup og Restore for Produktionsmiljøet og Præproduktionsmiljøet gennemføres i overensstemmelse med Driftskontraktens punkt 13.2 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.1.B.
• Inkludere en oversigt over gennemførte og ikke-gennemførte Backup/Restore, herunder i forhold til planen for Backup og Restore i den aftalte rapportering, jf. bilag 7.5. Dette gælder også Backup og Restore, som foretages af Leverandørens Underleverandø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 Produktionsmiljøet og Præproduktionsmiljøet, samt Systemet heri, herunder Konfigurationsmateriale og Data. . Processen skal samtidigt sikre minimal risiko 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.
• Sikre, at Restore kan gendannes fuldt (RTO) inden for Servicemålet for løsningstid for prioritet A Incidents.
• Opdatere procedurerne og planen for Backup og Restore kvartalsvist i forbindelse med Restore test.
• Sikre, at backupdata er placeret på en anden fysisk lokation end der, hvor Systemet drives. Ved fysisk distribueret drift kan backupdata dog anbringes på det sekundære driftscenter, men adskilt fra ikke-backupdata.
• Sikre, at alle backupdata altid er placeret i et sikret driftscenter. Sikring skal være svarende til sikring for primær og sekundær driftscenter
• Sikre, at Backups, som ikke er aktuelle, arkiveres på et sikkert og et til formålet omkostningseffektivt medie. Der skal altid mindst være 2 backups eller tilsvarende som gør det muligt at gennemføre Restore.
• 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 destruktion, herunder således at medarbejdere involveret i udførelsen af Ydelserne ikke har adgang til både backupdata og data i Driftsmiljøet.
7 INCIDENT MANAGEMENT
Leverandøren skal håndtere Incidents i henhold til Incident Management, som beskrevet under 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 aktiviteter begrænses mest muligt.
Fejl og Mangler i Systemet skal anses for Incidents. Kendte Fejl, som er godkendt af KOMBIT, håndteres ikke som Incidents, men behandles som en del af Release Management.
Incident Management processen skal gennemføres i overensstemmelse med følgende proces:
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.
3) Leverandøren orienterer (løbende) KOMBIT og øvrige Interessenter om Incidentet og dens håndtering, jf. punkt 7.9.
4) Leverandøren orienterer KOMBIT og øvrige Interessenter om, at Incidentet er løst, herunder med rapportering til KOMBIT, jf. punkt 7.10.
5) Incident Management processen afsluttes i forhold til de(n) konkrete Incident(s), medmindre KOMBIT kommer med indsigelser i forhold til Leverandørens rapport, jf. punkt 7.10.
Leverandøren skal i forbindelse med Ydelserne under Incident Management anvende IT Service Management systemet, der er beskrevet under punkt 9.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ølgende Ydelser:
• Foretage registrering af og opfølgning på indrapporterede Incidents, jf. punkt 9.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.
• Reagere på og foretage registrering af egne konstateringer af eller indikationer på Incidents, herunder i forbindelse med Events, jf. punkt 4.1.
• Foretage klassificering af Incidents for efterfølgende at kunne identificere relevante indsatsområder med henblik på bl.a. at reducere antallet af Incidents. Klassificeringen kan eksempelvis basere sig på typer som gentagne Incidents, hardware Incidents, Incidents på Integrationer mv.
• Prioritere Incidents i henhold til punkt 7.3 - 7.5.
• Løse Incidents, så Systemet og driften heraf genetableres til normal og som i Kontrakten forudsat tilstand, jf. punkt 7.6.
• Eskalering af Incidents til Tredjepartsprogrammelleverandør ved Incident, hvor årsagen til Incidentet skyldes eller kan skyldes forhold i Tredjepartsprogrammel fra den pågældende Tredjepartsprogrammelleverandør.
• Eskalering af Incidents til Tredjepartsprogrammelleverandør, Anvendersystemleverandør eller Afsendersystemleverandør ved Incident, hvor årsagen til Incidentet skyldes eller kan skyldes
forhold hos den pågældende Tredjepartsprogrammelleverandør, Anvendersystemleverandør eller Integrationsleverandører, herunder fejl i data.
• Løbende opfølgning på Incidents, herunder navnlig Incidents, der er eskaleret til Tredjepartsprogrammelleverandører samt Anvendersystemleverandører for at sikre den nødvendige fremdrift i afhjælpningen eller omgåelsen af forholdet/forholdene, der er årsag til Incident(s).
• Løbende orientering af KOMBIT om fremdrift i løsningen af Incidents eskaleret til Tredjepartsprogrammelleverandører, Integrationsleverandørereller Anvendersystemleverandø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, Integrationsleverandører eller Tredjepartsprogrammelleverandør og fremsendelse af analysen til KOMBIT. Såfremt Anvendersystemleverandør, Integrationsleverandø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 indrapportering af Incidents til Service Desk oprette et Incident Record og registrere følgende information:
• 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 9, eller Incidents konstateres af Leverandøren, herunder som led i driftsmonitoreringen.
[Resten af punkt 7.2 udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
Starttiden for et Incident (”Incidentstarttiden”) er, når Leverandøren som led i sin Incident Management proces, f.eks. ved en Event, eller i forbindelse med modtagelse af henvendelse til Service Desk eller til kontaktpersonen, jf. punkt 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 et foreløbig 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 opgaver, som Systemet anvendes 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æssig brist/risiko, herunder således, at der kan opnås uberettiget adgang til og/eller tab af personoplysninger, fortrolige oplysninger, økonomiske oplysninger eller lignende kritiske oplysninger. • Incidentet indebærer en kritisk forringelse af Systemets anvendelse, f.eks. i form af følgende: o Systemet er utilgængeligt for alle Brugere hos én eller flere Anvendere; o Systemet og/eller afgørende funktionalitet er utilgængeligt for mere end 20 % af samtlige Brugere; o Incidentet indebærer ukorrekte beregninger i Anvendersystemer; o Incidentet indebærer, at kritisk funktionalitet er utilgængelig; o Der sker nedbrud på netværksforbindelser, herunder til tredjeparter; • En Kritisk Batchkørsel, jf. punkt 7.5 afvikles kun delvist eller fejler; • En Kritisk Integration, jf. punkt 7.4, fejler eller fungerer kun delvist; • Tre eller flere Vigtige Integrationer, jf. punkt 7.4, fejler; • Systemets Servicemål for Maksimale Svartider, jf. punkt 13.5 og 13.6 med underpunkter, overskrides i et sådant omfang, at KOMBIT anser Systemet for utilgængeligt. |
Prioritet B Alvorlig Incident | Incidentet har eller vil have alvorlig indvirkning på Systemet og/eller løsningen af de opgaver, som | Et Incident har f.eks. alvorlig indvirkning, hvis en eller flere af følgende betingelser opfyldes: • Incidentet har alvorlig indvirkning på anvendelsen af Systemet, herunder på funktionalitet, indeks, |
Incidentprioritet | Beskrivelse | Eksempler i Produktionsmiljøet |
Systemet anvendes til eller for. | tabeller eller data, som Systemet udstiller fra Anvendersystem, som Systemet er tilsluttet, eller Systemets interne funktionalitet i øvrigt; • Systemet kan ikke anvendes af Brugerne hvor: o Mere end 50 % af Brugerne hos en Anvender 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 eller fungerer kun delvist • 3 Mindre Vigtige Integrationer, jf. punkt 7.4, fejler; • En Vigtig Batchkørsel, jf. punkt 7.5, afvikles kun delvist eller fejler; • En Mindre Vigtig Batchkørsel, jf. punkt 7.5, fejler gentagende gange resulterende i, at mere end 5 % af samtlige Brugere ikke kan anvende Systemet fuldt ud; • En Mindre Vigtig Integration, jf. punkt 7.4, fejler gentagende gange resulterende i, at mere end 5 % af samtlige Brugere ikke kan anvende Systemet fuldt ud; • En prioritet C eller D Incident, der kan forårsage en prioritet A eller B Incident; • Hvis dataelementer er beskadiget, tabt eller utilgængelige; • Input eller output data, elementer eller beskeder, der er klar til at blive processeret, har ventet på sådan processering i mere end 2 timer, medmindre andet fremgår af Leverancebeskrivelsen; • Systemets Servicemål for Ønskede Svartider, jf. punkt 13.5 og 13.6 med underpunkter, overskrides i et sådant omfang, at KOMBIT anser Systemet for delvist utilgængeligt | |
Prioritet C Betydende Incident | Incidentet har eller vil have betydende indvirkning på Systemet og/eller løsningen af de opgaver, som Systemet anvendes til eller for. | Et Incident har f.eks. betydende indvirkning, hvis en eller flere af følgende betingelser opfyldes: • 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 eller fungerer kun delvist; • En Mindre Vigtig Batchkørsel, jf. punkt 7.5, afvikles kun delvist eller fejler |
Prioritet D | Incidentet har eller vil have mindre betydende indvirkning på Systemet | Et Incident har f.eks. mindre betydende indvirkning, hvis følgende betingelse opfyldes: |
Incidentprioritet | Beskrivelse | Eksempler i Produktionsmiljøet |
Mindre betydende Incident | og/eller løsningen af de opgaver, som Systemet anvendes til eller for. | • En mindre betydende Incident, som medfører gene for Brugere eller Anvendere, men ikke blokerer for anvendelse; |
Tabel 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 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. Som alternativ til en eskalation i overensstemmelse med Driftskontraktens punkt 33 kan Parterne aftale, at afgørelsen på Parternes uenighed udskydes, herunder med mulighed for efterfølgende eskalation i overensstemmelse med Driftskontraktens punkt 33.
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ølgende 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 bestemmelser 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 eksempler:
Eksempel:
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 Leverandø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 et 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 Integrationer i følgende kategorier:
Integrationskategorier | Eksempler på Integrationer i Produktionsmiljøet | Incidentprioritering |
Kritisk Integration | • En Integration til et andet system som er afhængig af Integrationen | Fejl og andre driftsforstyrrelser ved |
Integrationskategorier | Eksempler på Integrationer i Produktionsmiljøet | Incidentprioritering |
Integrationen har kritisk betydning for Systemet og/eller løsningen af de opgaver, som Systemet anvendes til eller for. | i forbindelse med udbetalinger eller afgørelser i myndighedssager. • En Integration til et andet system 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. | sådanne Integrationer 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 system som er delvist afhængig af Integrationen i forbindelse med udbetalinger eller afgørelser i myndighedssager. • En Integration til et andet system 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 driftsforstyrrelser ved sådanne Integrationer skal som Incident prioriteres som prioritet B |
Mindre Vigtig Integration Integrationen har mindre vigtig betydning for Systemet og/eller løsningen af de opgaver, som Systemet anvendes til eller for. | • En Integration til et andet system, 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 driftsforstyrrelser ved sådanne Integrationer skal som Incident prioriteres som prioritet C |
Tabel 5: Integrationskategorier
De enkelte Integrationer kategoriseres som led af udviklingsarbejdet af KOMBIT i samarbejde med Leverandøren inden der gennemføres Overtagelsesprøve på disse påbegyndelse, 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.4.
Der er efter forudgående skriftlig aftale med KOMBIT mulighed for at nedgradere prioriteten af et Incident, hvis en konkret Fejl eller driftsforstyrrelse vurderes som mindre betydende, jf. følgende eksempel. KOMBIT kan afvise et ønske fra Leverandøren om at nedgradere 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 Incident 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 et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Såfremt der sker Fejl og andre driftsforstyrrelser i forhold til en Batchkørsel (herunder forsinkelse 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, kategoriseres alle Batchkørsler i følgende kategorier:
Batchkørsel kategorier | Eksempler på Batchkørsler i Produktionsmiljøet | Beskrivelse |
Kritisk Batchkørsel | En Kritisk Batchkørsel kan f.eks. være: • En Batchkørsel, hvor et andet system er 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 5 Anvendere • Batchkørslen indeholder kritisk data fra Anvendersystemer f.eks. vedrørende sikkerhed eller masseopdateringer fra registre. | Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som Incident prioriteres som prioritet A |
Vigtig Batchkørsel | • En Vigtig Batchkørsel kan være: • En Batchkørsel, hvor et andet system er delvist afhængig af Batchkørslen i | Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som Incident prioriteres som prioritet B |
Batchkørsel kategorier | Eksempler på Batchkørsler i Produktionsmiljøet | Beskrivelse |
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 persondata, som er følsomme eller semifølsomme. | ||
Mindre Vigtig Batchkørsel | En Mindre Vigtig Batchkørsel kan være: • En Batchkørsel, som påvirker et andet system, hvis Anvendere ikke er væsentligt påvirket. • Batchkørslen indeholder mindre vigtig data. | Fejl og andre driftsforstyrrelser ved sådanne Batchkørsler skal som Incident prioriteres som prioritet C |
Tabel 6: Batchkørsel kategorier
De enkelte Batchkørsler kategoriseres som led af udviklingsarbejdet af KOMBIT i samarbejde med Leverandøren inden der gennemføres Overtagelsesprøve for disse, og på baggrund af deres vigtighed i forhold til driftsafviklingen af Systemet og effekt for Brugere og Anvendere. Xxxxx Xxxxxxxxxxxx, som måtte tilføjes, kategoriseres af KOMBIT på Leverandørens foranledning. Er en Batchkørsel ikke kategoriseret, skal den kategoriseres som en Kritisk Batchkørsel. Batchkørsler skal dokumenteres i Driftshåndbogen, jf. bilag 7.4.
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 beskrevet, jf. følgende eksempel. KOMBIT kan afvise et ønske fra Leverandøren om at nedgradere 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 erklæ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 Incident, 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 Servicemå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 aktiviteter, 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 overholde Driftskontraktens garantier og øvrige bestemmelser, jf. herunder Driftskontraktens punkt 5 og 6.
Incidents anses først for løst, når Systemet og driften heraf er returneret til normal drift og en tilstand, hvor Systemet kan anvendes i henhold til Kontrakten, og de(n) pågældende Incidents indvirkning(er) på Anvendernes anvendelse og anvendelsesmuligheder af Systemet er minimal. Såfremt fuldstændig Omgåelse/afhjælpning af et Incident ikke umiddelbart er mulig, har Leverandøren uden ugrundet ophold pligt til at implementere delvis Omgåelse/afhjælpning, således at Incidentets ulempe for KOMBIT til enhver tid er mindst mulig. Delvis Omgåelse/afhjælpning skal godkendes af KOMBIT. Godkendelse af en delvis Omgåelse/afhjælpning af et Incident anses ikke som løsning af et Incident, dog kan KOMBIT vælge at nedsætte prioriteten for Incidentet, jf. punkt 7.3.
[Punkt 7.6.1 udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Ved Omgåelse fjernes Incidentets effekt på og/eller risiko for effekt på Systemets anvendelighed 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 eliminering af Incidentets Root Cause. For at en fuldstændig Omgåelse af et Incident kan accepteres 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 et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Ved afhjælpning fjernes dels Incidentets effekt på og/eller risiko for effekt på Systemets anvendelighed 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 jf. punkt. 7.6, 7.6.1 og 7.6.2, således at Systemet fungerer og kan anvendes i
overensstemmelse med Kontrakten, herunder i overensstemmelse med Servicemålene angivet i indeværende bilag.
Leverandøren skal på proaktiv vis holde sig orienteret om fejl og servicevinduer og planlagte ændringer hos relevante leverandører, f.eks. Anvendersystemleverandører, Integrationsleverandører, samt ændringer til Tredjepartsprogrammel, f.eks. nye versioner af programmel. Dette kan være gennem overvågning af diverse hjemmesider og gennem initiativ til koordineringsmøder med disse leverandører o.a.
Leverandøren har således også det overordnede koordinerings- og opfølgningsansvar over for Anvendersystemleverandører, Integrationsleverandører og Tredjepartsprogrammelleverandører i forhold til Incidents, som skyldes fejl eller andre forhold i henholdsvis Anvendersystemer og Tredjepartsprogrammel. Leverandøren kan dog ikke stilles til ansvar for funktionaliteten og/eller tilgængeligheden af Anvendersystemer henholdsvis Tredjepartsprogrammel.
Uanset om Incidents er forårsaget af fejl/forhold i Anvendersystemer eller i Tredjepartsprogrammel, gælder således følgende:
• Leverandøren skal straks rapportere fejlen/det pågældende forhold til den pågældende 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, Integrationsleverandører og Tredjepartsprogrammelleverandører skal Leverandøren proaktivt sikre, at disse bekræfter over for Leverandøren, at forholdet 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 eskalation.
• Når Tredjepartsprogrammelleverandører har leveret en rettelse af en fejl eller anvist relevant Omgåelse, skal Leverandøren straks sørge for orientering af KOMBIT samt installation via Change Management processen i Driftsmiljøet efter behørig test, jf. punkt 16.
Når fejlen/forholdet, der forårsagede Incidentet, er afhjulpet, skal Leverandøren uden ugrundet 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 et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Servicemål for Incident Management baserer sig på reaktionstider, jf. punkt 7.7.1, løsningstider, 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 Incidents, 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.
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 registrering 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 involverede parter. Servicemål for reaktionstiden gælder, uanset om Incidents, herunder Fejl, skyldes Leverandørens forhold eller andre forhold, herunder Tredjepartsprogrammelleverandører, Anvendersystemleverandører eller Integrationsleverandø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.
Leverandøren skal måle og rapportere hele løsningstiden fra Incidentet starter, til det er løst. Leverandøren kan således ikke stoppe tiden undervejs i løsningsforløbet. Leverandøren kan dog ved opgørelsen af egen målopfyldelse efter forudgående skriftlig aftale med KOMBIT fradrage evt. tidsperioder, hvor Leverandøren afventer ekstern afklaring (fra tredjepart) af forhold eller udbedring af fejl, der er uden for Leverandørens ansvar under Driftskontrakten.
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 Leverandøren tydeligt informerer KOMBIT om alternativ arbejdsgang for Systemets anvendelse (Omgåelse). Såfremt dette ikke er muligt, skal Leverandøren skriftligt inden for løsningstiden dokumentere, hvorfor det ikke er muligt for Leverandøren at løse Incidentet, herunder udarbejde et udkast til en skriftlig orientering af berørte Interessenter, jf. punkt 7.9, som skal forelæ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, Integrationsleverandøren og/eller Tredjepartsprogrammelleverandøren om forholdet. Eskaleringstider måles alene inden for deres åbningstid.
Leverandøren skal aktivt og med intervaller svarende til Servicemålene for eskaleringstiderne følge op på afhjælpningen og rapportere status til KOMBIT.
I tilfælde af eksempelvis en prioritet A Incident skal Leverandøren således i Måleperiode 1 følge op på afhjælpningen hver 60. minut, jf. punkt 7.7.4, samt rapportere status til KOMBIT, jf. punkt 7.9.
I forhold til prioritet B Incidents skal Leverandøren følge op på afhjælpningen hver 120. minut, jf. punkt 7.7.4, samt rapportere status til KOMBIT, jf. punkt 7.9.
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 Arbejdsdag.
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, Integrationsleverandør eller en Tredjepartsprogrammelleverandør, og viser det sig efterfølgende, at Leverandøren selv var ansvarlig for Incidentet, 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), Integrationsleverandø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 tabeller skal opfyldes med 90 % fraktilen for alle målte tider i løbet af en kalendermåned.
Servicemål for Incident Management i perioden Arbejdsdage 08.00-16.00 (”Måleperiode 1”) | Reaktionstid | Eskaleringstid | Løsningstid |
Prioritet A Incidents | 30 minutter | 60 minutter | 180 minutter |
Prioritet B Incidents | 60 minutter | 120 minutter | 360 minutter |
Prioritet C Incidents | 300 minutter | 1 Arbejdsdag | 3 Arbejdsdage |
Prioritet D Incidents | 3 Arbejdsdage | 3 Arbejdsdage | 15 Arbejdsdage, medmindre Parterne aftaler andet |
Tabel 7: Servicemål for Incident Management i Måleperiode 1
Servicemål for Incident Management uden for perioden Arbejdsdage 08.00-16.00 (”Måleperiode 2”) | Reaktionstid | Eskaleringstid | Løsningstid |
Prioritet A Incidents | 60 minutter | 60 minutter | 360 minutter |
Prioritet B Incidents | 120 minutter | 120 minutter | 480 minutter |
Prioritet C Incidents | Kl. 09.00 næstkommende Arbejdsdag | 1 Arbejdsdag | 3 Arbejdsdage |
Prioritet D Incidents | 3 Arbejdsdage | 3 Arbejdsdage | 15 Arbejdsdage, medmindre Parterne aftaler andet |
Tabel 8: Servicemål for Incident Management i Måleperiode 2
Ved overlap mellem de to måleperioder gælder følgende for alle Servicemål:
Hvis et Servicemål, der er trådt i kraft i én måleperiode, lapper ind over den anden måleperiode, gælder Servicemålene i den nye måleperiode. Dog gælder det for Servicemål, der er trådt i kraft i Måleperiode 2, at Servicemålet for Måleperiode 2 altid udgør det maksimale Servicemål. Se nedenstående eksempler:
Eksempel 1: Et prioritet A Incident konstateres fredag kl. 15.50 (Måleperiode 1). Fristen for løsning af Incidentet (180 minutter/3 timer) rækker ind Måleperiode 2. Fristen for løsning regnes derfor fra Måleperiode 2’s begyndelse og i henhold til den frist, der gælder i Måleperiode 2 (6 timer). Dvs. fristen udløber 6 timer efter fredag kl. 18. dvs. fredag kl. 24.00.
Eksempel 2: Et prioritet A Incident konstateres mandag kl. 07.45 (Måleperiode 2). Fristen for løsning af Incidentet (360 minutter/6 timer) rækker ind i Måleperiode 1. Fristen for løsning regnes derfor fra Måleperiode 1’s begyndelse og i henhold til den frist, der gælder i Måleperiode 1 (180 minutter/3 timer). Dvs. fristen udløber mandag kl. 11.00.
Eksempel 3: Et prioritet A Incident konstateres mandag kl. 3.00 (Måleperiode 2). Fristen for løsning (360 minutter/6 timer) rækker ind i Måleperiode 1. Fristen for løsning regnes derfor som udgangspunkt fra Måleperiode 1’s begyndelse og i henhold til den frist, der gælder i Måleperiode 1 (180 minutter/3 timer). Dvs. at fristen udløber kl. 09.00 mandag. I dette tilfælde gælder imidlertid reglen om, at fristen aldrig kan overstige Servicemålet for Måleperiode 2, idet fristen herefter – 360 minutter/6 timer fra mandag kl. 3.00 – udløber mandag kl. 09.00. Fristen udløber dermed i dette eksempel mandag kl.
09.00.
7.8 Kontaktperson til KOMBITs rapportering af Incidents
Leverandøren skal sikre, at KOMBIT ud over muligheden for at henvende sig til Service Desk, jf. punkt 9, har mulighed for at rapportere Incidents via telefon og mail til den i Driftshåndbogen angivne kontaktperson. Adgangen til telefonisk indrapportering skal gælde 24/7 for så vidt angår Incidents, der kandiderer til prioritet A eller B.
Leverandøren skal i Driftshåndbogen anføre KOMBITs kontaktpersoner, eksempelvis Service Delivery Manager og Incident Manager
7.9 Eskalering til KOMBIT samt orientering om Incidents til Brugere og øvrige Interessenter
For alle Incidents, der er prioriteret som prioritet A og B, og uanset om Incidentet er forårsaget 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 organisation samt med alle Interessenter.
Leverandøren skal eskalere alle kritiske forhold, herunder i forhold til samarbejdet med Tredjepartsprogrammelleverandører, Anvendersystemleverandører eller Integrationsleverandører til KOMBITs driftschef, ligesom Leverandøren løbende skal holde Interessenterne orienteret om kritiske forhold i forhold til Incidents.
Leverandørens Ydelser omfatter navnlig følgende:
• Eskalering til KOMBIT via telefon, SMS og mail. Kontaktinformation fremgår af Driftshåndbogen.
• Efter eskalering skal Leverandøren løbende orientere KOMBIT minimum hver time i Måleperiode 1 og hver 3. time i Måleperiode 2, 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, Integrationsleverandører eller Tredjepartsprogrammelleverandører.
• Løbende publicering af information for Brugere og Interessenter. Dette omfatter kommunikation ved hjælp af mail, Systemets hjemmeside samt gennem automatisk velkomsthilsen på telefonindgangen før gennemstilling til Service Desk. Desuden udstilles informationer om driftsstatus via Systemet.
• Pligt til med et varsel på 30 minutter i både Måleperiode 1 og 2 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 omhandlende Omgåelse og afhjælpning af prioritet A og B Incidents.
7.9.1 Servicemål for orientering af KOMBIT og Interessenter
KOMBIT skal orienteres om Incidents i overensstemmelse 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æsentant 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 informationen herom være tilgængelig for Brugere og Interessenter på velkomsthilsen på telefonindgangen, en Systemets hjemmeside og/eller mail til berørte Brugere og Interessenter med driftsstatus
• Leverandøren skal mindst hver anden time opdatere både driftschef per telefon eller efter aftale samt opdatere Systemets hjemmeside og/eller mail.
• Leverandøren skal løbende orientere om status på prioritet A og B Incidents på Systemets hjemmeside og/eller mail til berørte Brugere og Interessenter med en frekvens på ikke mindre end 2 timer.
Servicemål inden for Måleperiode 2:
• Prioritet A og B Incidents skal meddeles KOMBITs driftschef inden for 1 time fra Incidents er oprettet, primært på telefon, sekundært via SMS og mail
• Inden for 1 time fra prioritet A eller prioritet B Incidents er oprettet, skal informationen herom være tilgængelig for Brugere og Interessenter på velkomsthilsen på telefonindgangen, Systemets hjemmeside og/eller mail til berørte Brugere og Interessenter med driftsstatus
• Leverandøren skal mindst hver tredje time opdatere både driftschef eller denne repræsentant per telefon eller efter aftale samt opdatere Systemets hjemmeside og/eller mail.
• Leverandøren skal løbende orientere om status på prioritet A og B Incidents på Systemets hjemmeside og/eller mail til berørte Brugere og Interessenter med en frekvens på ikke mindre end 3 timer.
Tiden for orientering af KOMBITs driftschef måles fra Incidentstarttiden, jf. punkt 7.2, til Leverandøren har meddelt Incidentet til KOMBITs driftschef. Leverandøren skal i IT Service Management systemet logge tidspunkter for forsøg på at opnå telefonisk kontakt med samt afsendelse af SMS og mail til KOMBITs driftschef.
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 incidentrapporten 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 det samlede tidsrum, der skal fratrækkes Tilgængelig Driftstid som følge af Incidentet, jf. punkt 12.
• 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 yderligere 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 henhold til Driftskontraktens punkt 33.
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.
8 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å Kontraktens krav, herunder såvel funktionsmæssige som driftsmæssige, og forudsætninger er opfyldt.
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 Driftskontrakten.
Af punkt 8.1 fremgår, hvilke forhold, herunder navnlig Incidents, der skal håndteres som Problems, idet de nærmere Ydelser under Problem Management er beskrevet under punkt 8.2.
Leverandøren skal i forbindelse med Ydelserne under Problem Management anvende et IT Service Management system, der er beskrevet under punkt 9.2, herunder til registrering af Problems.
8.1 Problems
Problems kan identificeres blandt andet i følgende processer, hvilket medfører en oprettelse af en Problem Record, som skal behandles af Problem Management:
• 2nd and 3rd level Support
• Problem Management
• Incident Management
• Event Management
• Service Desk
Hvis Problems indrapporteres via Incident Management eller Event Management gælder, at Leverandøren straks skal oprette en Problem Record, hvis mindst et af følgende punkter er opfyldt:
1. 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 gentagende.
3. Events, der viser en væsentlig negativ trend.
4. Udvalgte Events eller Incidents på KOMBITs anmodning, dog højst 12 om året. Events påpeget af KOMBIT, der viser en væsentlig negativ trend er omfattet af punkt 3, og tæller dermed ikke med i de maksimale 12 Events, der kan påpeges af KOMBIT i medfør af dette punkt.
For hver Problem Record skal Problem Management identificere og håndtere de bagvedliggende årsager, herunder Fejl, som beskrevet under nærværende punkt 8.
Et Problem anses som indrapporteret, når en af ovennævnte processer for første gang henvender sig til Problem Management vedrørende håndtering af det specifikke Problem.
8.2 Ydelser under Problem Management
Leverandøren skal som led i Problem Management identificere Root Cause(s) for de Incidents, der eskaleres som Problems til Problem Management, afhjælpe de Problems, som Leverandøren er ansvarlig for, jf. punkt 8.4, samt bistå med afhjælpning af Problems, som Leverandøren ikke er ansvarlig for, jf. punkt 8.5.
Såfremt et Incident udspringer af flere forskellige medvirkende Problems og/eller Root Causes, 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 ansvarlig 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 sammenhæng, så Problem Management processen optimeres, og risikoen for Incidents begrænses mest muligt.
Leverandørens Ydelser er generelt som følger:
• Modtagelse af indrapportering af Problem Record.
• Registrering og prioritering af Problems, jf. punkt 8.3.
• Identificering og dokumentering af Root Cause for Problems.
• Leverandøren skal, på KOMBITs anmodning, anmode Tredjepartsprogrammelleverandører, Anvendersystemleverandører og Integrationsleverandører om at få identificeret og dokumenteret Root Cause for Problems for alle prioritet A og B Incidents, der skyldes forhold i Tredjepartsprogrammel eller Anvendersystemer.
• Sikring af afhjælpning af Problem, herunder at anmode om gennemførelse af Change gennem Change Management og Release Management, såfremt dette er påkrævet.
• Dokumentering af afhjælpningen af Problems og Root Causes. Dette omfatter at opdatere Known Error Database. Ved forebyggende vedligeholdelse skal Leverandøren oplyse arten heraf.
Leverandøren skal løbende og mindst hver anden uge orientere KOMBIT omkring status på ovenstående punkter og håndtering af alle åbne Problem Records, herunder plan for diagnosticering og afhjælpning af
Problems og Root Causes. Tilsvarende fremlægges Problem Management status for KOMBIT ved driftsgruppemøder. Kategorisering og prioritering af Problem Records kan evt. foregå på samme møde. Der henvises til bilag 7.5.
8.3 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 prioriteres som et prioritet A Problem.
• Har et Problem været årsag til flere Incidents, prioriteres det pågældende Problem i overensstemmelse med den højest prioriterede Incident.
• Er et Incident i forbindelse med og/eller som følge af Incident Management processen nedprioriteret, skal det Problem, der har været årsag til den pågældende Incident, prioriteres i overensstemmelse med den højeste 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ælder, 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ælpes 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. Som alternativ til en eskalation i overensstemmelse med Driftskontraktens punkt 33, kan Parterne aftale, at afgørelsen på Parternes uenighed udskydes, herunder med mulighed for efterfølgende eskalation i overensstemmelse med Driftskontraktens punkt 33.
Indtil spørgsmålet om kategorisering af og/eller ansvaret for afhjælpning af Problems er afgjort, skal Leverandøren håndtere det pågældende Problem i henhold til KOMBITs beslutning. 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 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 bestemmelser om udførelse af timebaserede ressourcer.
8.4 Problems, som Leverandøren er ansvarlig for
For alle Problems, herunder Fejl, som Leverandøren er ansvarlig for, skal Leverandøren afhjælpe de pågældende Problems inden for afhjælpningstiderne, jf. punkt 8.4.1. Dette gælder uanset, om et Problem skyldes Fejl i Programmel, i Konfigurationsmateriale, i Leverandørens Ydelser og/eller forhold i øvrigt, som Leverandøren er ansvarlig for.
Efter afhjælpning af Problems skal såvel Systemet i Driftsmiljøet som Leverandørens øvrige Ydelser således opfylde Kontraktens krav, herunder således at konstaterede Fejl er afhjulpet.
8.4.1 Servicemål for afhjælpning af Problems
Problems skal afhjælpes inden for den afhjælpningstid, der gælder for prioriteten af det pågældende Problem, medmindre andet aftales.
Servicemål for Problem Management | |
Afhjælpningstider | Servicemål |
Tid til afhjælpning Prioritet A Problem | 15 Arbejdsdage |
Tid til afhjælpning Prioritet B Problem | 30 Arbejdsdage |
Tid til afhjælpning Prioritet C Problem | 90 Arbejdsdage |
Tid til afhjælpning Prioritet D Problem | 180 Arbejdsdage |
Tabel 9 Servicemål for afhjælpning af Problems
Afhjælpningstiden er tiden fra indrapportering af et Problem, jf. punkt 8.1, til Leverandøren har afhjulpet det pågældende Problem i Systemet i Driftsmiljøet, medmindre andet aftales.
8.5 Problems, som Leverandøren ikke er ansvarlig for
For de Problems, som Leverandøren ikke er ansvarlig for, herunder fejl i Tredjepartsprogrammel og fejl i Anvendersystemer, skal Leverandøren proaktivt følge op på status og rapportere herpå ved driftsgruppemøder, jf. punkt 8.2.
Leverandøren skal herunder gøre nødvendige tiltag for at minimere risikoen for, at det pågældende Problem medfører nye Incidents.
8.6 Servicemål for Root Cause Analyser
Det er et Servicemål, at en orientering indeholdende Root Cause Analyse for prioritet A og B Problems i 95
% af alle tilfælde per kalendermåned skal være KOMBIT i hænde senest 5 Arbejdsdage 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 Tredjepartsprogrammelleverandører, Anvendersystemleverandører, Integrationsleverandø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, Anvendersystemleverandører, Integrationsleverandører eller Anvendere.
9 SERVICE DESK
Supportansvaret omfatter at give adgang til en effektiv Service Desk. Leverandøren skal fra Overtagelsesdagen for Basisløsningen, jf. bilag 1, håndtere alle henvendelser og yde support til supportberettigede Brugere, KOMBIT, KOMBITs repræsentanter samt Anvendersystemleverandører, Integrationsleverandører og Tredjepartsprogrammelleverandører. De supportberettigede Brugere er navngivne brugere i kommunerne. 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 9.1
• Modtagelse og håndtering af henvendelser om Incidents, jf. punkt 9.4
• Løbende holde Brugere informeret om status på ikke-afsluttede henvendelser ved hjælp af telefon, SMS, mail og/eller hjemmeside.
• Holde Brugere orienteret om planlagte tiltag formidlet på en måde, at informationen kan forstås af Brugere og supportberettigede Brugere med begrænset it-viden.
• Etablering, vedligeholdelse og anvendelse af IT Service Management system, jf. punkt 9.2
• Modtagelse og håndtering af henvendelser om Service Requests, jf. punkt 10
• Anvendelsesorienteret support dvs.hjælp til funktionel anvendelse af Systemet.
• Udvidet Service desk i en afgrænset periode ifm. kommunens ibrugtagning af Systemet. Dette sker via Leverandørens Service desk, hvor der er allokeret særlig kapacitet og ressourcer for at sikre en effektiv og hurtig håndtering af opståede tekniske og brugermæssige udfordringer. Kommunen vil have umiddelbar adgang til Leverandøren i denne periode.
• Levere dataudtræk over supporthenvendelser, jf. punkt 9.5
• Oprette, nedlægge og administrere supportberettigede Brugere af Service Desken
• Oprette, nedlægge og administrere Brugere på øvrige miljøer ud over Produktionsmiljøet.
• For så vidt angår hjælp til anvendelse af Systemet ydes denne service kun i Service Deskens åbningstid
• Leverandøren skal stille funktionalitet til rådighed for kommunerne og KOMBIT til løbende at opdatere informationen om de supportberettigede Brugere.
• Når behandlingen af en henvendelse fra en supportberettiget Bruger er afsluttet, skal Leverandøren foretage måling af tilfredsheden hos den supportberettigede Bruger med håndteringen af henvendelsen. Målingen skal gennemføres for minimum 10 % af de afsluttede sager i en måned, dog mindst 10 sager. Sagerne skal udvælges tilfældigt. Leverandøren skal rapportere resultatet af målingerne månedsvist, jf. bilag 7.5, og håndtere fald i rapporterede brugertilfredshed.
9.1 Supportorganisation
Leverandøren skal etablere en supportorganisation, herunder Service Desk, i overensstemmelse 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. Fokus 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 varetages typisk af fagpersonale hos Leverandøren med særlige kompetencer inden for disse områder.
• Såfremt Anvendersystemleverandører, Integrationsleverandø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 aftalegrundlag 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 og Integrationsleverandørs opkobling og vedligeholdelse af Eksterne Snitflader.
Leverandører af henholdsvis Anvendersystemer og Tredjepartsprogrammel leverer support på henholdsvis deres respektive Eksterne Snitflader for Integrationer og Tredjepartsprogrammel, hvilket dog ikke fritager Leverandøren for sit opfølgningsansvar, jf. punkt 7.7.3.
Kontaktoplysninger for henvendelse til Service Desk fremgår af Driftshåndbogen.
9.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 og Events om Incidents, Fejl, Problems, 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. KOMBIT skal have adgang til samtlige sager i IT Service Management systemet
IT Service Management systemet, der stilles til rådighed af Leverandøren, skal bl.a. understøtte følgende funktionalitet:
• Adgang til information om og statistik på alle registrerede Incidents, Problems, Changes og Service Requests
• Registrering af følgende information:
o Registrering af Incidents, Problems, Changes og Service Requests skal omfatte informationer, som angivet under punkt 7, punkt 8 og punkt 10.
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
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, Fejl, 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. Leverandø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 systemet ud fra parametre angivet af KOMBIT. Udtrækkene kan f.eks. omfatte oversigt over Incidents, Fejl, Problems, Service Requests og Changes. Udtrækkene skal på KOMBITs anmodning vise fuld sags- og aktivitetshistorik. 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 driftseffektivitetsmålinger.
Udtrækkene skal bearbejdes af Leverandøren til et maskinlæsbart format, f.eks. CSV eller Excel, ud fra parametre angivet af KOMBIT. Udtrækkene skal leveres til KOMBIT senest 2 Arbejdsdage regnet fra KOMBITs anmodning.
9.3 Systemets hjemmeside
For at sikre tilstrækkelig information til Systemets Anvendere skal Leverandøren etablere en hjemmeside hvor relevante oplysninger om Systemet skal udstilles.
Leverandøren ansvarlig for design, udvikling, drift, vedligeholdelse, videreudvikling og dokumentation af Systemets hjemmeside. Hjemmesiden skal designes af Leverandøren i samarbejde med KOMBIT, som Leverandøren skal anvende. KOMBIT er på Leverandørens foranledning ansvarlig for løbende fornyelse af supporthjemmesidens DNS navn.
Hjemmesiden skal være tilgængelig selvom Systemet er utilgængeligt, dvs. hjemmesiden bør ikke placeres på en af Systemets servere.
Leverandøren skal sikre, at adgang til indhold på hjemmesiden kan begrænses gennem rettighedsstyring. Der forventes op til 5 rettighedsgrupper (Brugere, Anvendersystemleverandører, CMS administrator, o.a). Adgang til hjemmesiden eller dele heraf skal kunne beskyttes med brugernavn/password, dog skal KOMBIT, kommunerne og Anvendersystemleverandører have direkte adgang uden login (single sign-on fra Systemet. Her skal Leverandøren administrere og vedligeholde adgang og indhold til hjemmesiden.
Generelt er det Leverandørens ansvar at udarbejde og publicere indhold til hjemmesiden, men KOMBIT skal kunne tilgå og opdatere dele af hjemmesiden med f.eks. kommunerettet information eller besvarelse af ændringsønsker over for Anvenderne.
Det er Leverandørens ansvar, at følgende information fremgår og holdes opdateret på den dertil indrettede hjemmeside.
• Realtime tilgængelighed at Systemets centrale services |
• Systemets 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 opdatering af status for Incidentet, samt når løst med løsningstidspunkt o Aktuelt driftsstatus på Systemets systemgrænseflader, herunder driftsstatus på Integrationer til Afsendersystem(er). |
• Aktuel driftsstatus på de miljøer, jf. Bilag 7.3, som er tilgængelige for Anvendere |
• Kendte og oprettede Fejl, som berører Anvendernes mulighed for at arbejde problemfrit i Systemet. |
• Fejl/Incidents skal være beskrevet med status og evt. løsningshorisont (f.eks. med angivelse af release og dato, hvor Fejl/Incidents forventes udbedret). |
• Anvenderne skal kunne tilkendegive om de oplever samme Fejl/Incident. Herved vil Leverandøren kunne begrænse at flere sagsbehandlere end nødvendigt kontakter supporten om samme Fejl/Incident. |
• Omgåelse til kendte Fejl/Incidents skal være beskrevet, så det er muligt for Anvenderne at anvende Systemet med så få gener som muligt |
• Information og varsling om kommende Changes og Patches til og Versioner af Systemet |
• Tekniske krav (systemforudsætninger) |
• Information om konkrete videreudviklingstiltag med tilhørende plan for implementering |
• Generelle nyheder og release noter herunder seneste og tidligere release noter til Systemet |
• Planlagte servicevinduer/lukkevinduer |
• Ændringsønsker og deres status |
• Dokumentation herunder brugerdokumentation og andre Anvenderrettede vejledninger |
• FAQ |
• Adgang til ”online lektioner” |
• Anden relevant support information til Systemets Anvendere, f.eks. o betingelser for anvendelse af Service Desk, o integrationsbeskrivelser o teknisk dokumentaion o fejlkoder o relevante dele af ydelseskataloget o offentlige certifikater |
Anvenderne skal via hjemmesiden kunne melde bl.a. ændringsønsker og spørgsmål, som udstilles på hjemmesiden.
Historiske driftsstatus annonceringer skal være tilgængelige på hjemmesiden. Det skal være muligt at hjemmesiden besøgende kan filtrere på hvilke annonceringer, som ønskes vist, eksempelvis aktuelle annoncering, kommende servicevinduer o.lign.
KOMBIT kan vælge også at udbyde webservice og/eller design af siden. I dette tilfælde vil Leverandøren fortsat holde indhold på hjemmesiden opdateret, som angivet i dette afsnit eller efter aftale med KOMBIT.
Supportsiden skal senest være klar 6 måneder før Overtagelsesdagen for Basisløsningen.
Hjemmesiden designes i samarbejde med KOMBIT. KOMBIT skal kunne tilgå og opdatere dele af hjemmesiden med f.eks. kommunerettet information eller uddannelsesmateriale.
KOMBIT har ansvar for indkøb og løbende fornyelse af hjemmesidens domæne/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 hjemmesidens indhold som angivet i dette afsnit eller efter aftale med KOMBIT.
9.4 Servicemål for Service Desk
Leverandøren skal på KOMBITs anmodning give adgang til alle informationer om alle registrerede Incidents, Problems og Service Requests, senest 3 Arbejdsdage efter anmodning herom.
Servicemålene for Service Desk er beskrevet 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 opkald | Leverandørens Service Desk skal åben for telefonhendelser på alle Arbejdsdage kl 08:00 – 16:00 For henvendelser via mail og webformular: Måleperiode 1 og 2. | Måles og dokumenteres af Leverandøren. |
Generelt for henvendelser | Antal henvendelser | Alle henvendelser skal registres i Leverandørens IT Service Management system. | Måles og dokumenteres af Leverandøren. |
Telefon henvendelser | Henvendelser til Leverandørens Service Desk via telefon. | Personen, som henvender sig, må ikke blive mødt af en optagettone. Varighed af evt IVR inklusive welcome speach må ikke overstige 40 sekunder, regnet fra telefonisk forbindelse til telefonsystemet hos Service Desk. | Dokumenteres af Leverandøren i telefonsystemet. |
Den gennemsnitlige telefonventetid må ikke overstige 3 minutter over en kalendermåned. | |||
Telefonventetiden må for hvert enkelt opkald ikke overstige 10 minutter. | |||
Henvendelser via mail og webformular | Henvendelser til Leverandørens Service Desk via mail eller webformular. | Personen, der henvender sig, skal modtage en personlig reaktion på henvendelsen indenfor • 3 timer for 90% af henvendelserne • 5 timer for 95% af henvendelserne • 24 timer for 100% af henvendelserne | Dokumenteres i Leverandørens IT Service Management system. |
Den personlige reaktion skal være enten med løsning eller med besked på, hvordan og hvornår henvendelsen vil blive håndteret. En Incidents starttidspunkt kan aldrig være senere end henvendelsestidspunktet. | |||
Servicemål for Service Desk | |||
Område | Definition | Servicemål | Måling |
Afslutning af sager 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 reset. | 65 % af alle henvendelser opgjort for en kalendermåned af gangen skal være afsluttet ved første henvendelse i Service Desk. | Dokumenteres i Leverandørens IT Service Management system. |
Supportkvalitet | Sikre, at medarbejdere i Service Desken har den fornødne viden til at yde en kompetent support. | Medarbejderne har som minimum gennemgået Leverandørens egen uddannelse for superbrugerne | Dokumentation for gennemført uddannelse for kompetent support på Systemet |
Tabel 10: Servicemål for Service Desk
For telefoniske henvendelser er telefonventetiden den tid, der går fra, der er telefonisk forbindelse til telefonsystemet hos Service Desk, og til personale hos Service Desk besvarer opkaldet og påbegynder modtagelse af henvendelsen. Såfremt Leverandøren anvender en telefonsluse går telefonventetiden fra det tidspunkt, hvor brugeren har valgt personlig henvendelse.
Leverandøren er på anmodning fra KOMBIT forpligtet til at give KOMBIT indsigt i Leverandørens målinger for Servicemål for Service Desk.
9.5 Dokumentation af henvendelser til Service Desk
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.5, skal Leverandøren levere en opgørelse (opgørelse 1) indeholdende statistik samt en opgørelse af periodens henvendelser. Opgørelse 1 skal leveres 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 Bruger, Anvendersystemleverandør,KOMBIT o.lign.
• Henvendelsesform (telefon, mail, web eller andet)
• Henvendelseskategori (Incident eller Service Request, herunder type af Service Request)
• Henvendelsens indhold (resume eller sagens indhold)
10 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 forudgående aftalte Standard Changes eller bestilling og håndtering af eventuelle standardydelser.
Leverandøren skal levere følgende Ydelser i forbindelse med Request Fulfilment:
• Udarbejde og vedligeholde et ydelseskatalog indeholdende oversigt over Request Fulfilment ydelser, og andre standardydelser, med fastsatte Servicemål for reaktionstid og løsningstid
• Dele af ydelseskataloget skal publiceres, så det er tilgængeligt for Anvendere og Brugere på Systemets hjemmeside, jf. punkt 9.3
• Modtagelse af og besvarelse af henvendelser om Service Requests, jf. punkt 9
• Registrering af henvendelsen til Service Desk som en Service Request, jf. punkt 9
• Klassificering af henvendelser om Service Requests for efterfølgende at kunne identificere 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.5. Derefter skal de godkendte Standard Changes ikke godkendes enkeltvis af Change Advisory Board, men kan udføres af Service Desk i overensstemmelse med forhåndsgodkendelsen.
10.1 Indrapportering af information om Service Requests
Leverandøren skal sikre, at der i forbindelse med henvendelser om Service Requests til Service 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 ønskes udført
• Eventuelle bilag til belysning af den pågældende Service Request Oplysningerne skal indrapporteres i IT Service Management systemet.
10.2 Forhåndsdefinerede Service Requests
KOMBIT har krav om nedenstående standardydelser som kan bestilles som Service Requests. Det skal være muligt at definere nye standardydelser eller ændre bestående efter aftale mellem Parterne.
Standardydelserne kan bestilles af KOMBIT og KOMBIT godkendte tredjeparter et ubegrænset antal gange, ligesom KOMBIT kan annulere bestilte standardydelser.
Vederlaget for standardydelserne afregnes enten som engangsvederlag og/eller løbende vederlag i henhold til bilag 7.2. Leverandøren skal fakturere bestillende tredjeparter direkte, hvis KOMBIT anmoder herom. I forhold til standardydelserne med løbende vederlag kan KOMBIT stoppe standardydelsen med et varsel på 1 måned
10.2.1 Udarbejdelse af systemspecifik revisionserklæring
Service Request | Systemspecifik revisionserklæring |
Kort beskrivelse | Leverandøren skal udarbejde en systemspecifik revisionserklæring eksempelvis en ISRS 4400 eller ISAE 3000, udover dem, som er en del af det faste vederlag Erklæringen skal følge retningslinjerne for indhold nævnt i punkt 25.2. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 90 dage |
10.2.2 Service Desk-ydelser før Overtagelsesdagen for Basisløsningen
Service Request | Service Desk-ydelser før Overtagelsesdagen for Basisløsningen, jf. bilag 1 |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse levere Service Desk- ydelser som beskrevet i punkt 9, således det er muligt at få hjælp til eksempelvis test og bestillinger. Bemærk, at Leverandøren fra Overtagelsesdagen for Basisløsningen skal levere Service Desk-ydelser som beskrevet i punkt 9 som del vederlaget for henvendelser om support til Service Desk i bilag 7.2. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid: 30 Dage |
10.2.3 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, Integrationsleverandø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ældende for alle services fra Systemet i Driftsmiljøet • Oprette Anvendersystemleverandør i IT Service Management systemet, således at disse kan oprette Incidents, Service Requests mv. • Dokumentation af opsatte Integration Efter oprettelsen af teknisk adgang, skal Leverandøren deltage i Anvendersystemets test og rådgivning af Anvendersystemleverandøren i et rimeligt omfang, dog maksimalt 1 Arbejdsdag. Denne standardydelse vedrører ikke videreudviklingsopgaver, som måtte være nødvendige for udnyttelse af den opsatte Integration. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 20 Arbejdsdage |
10.2.4 Supplerende Testmiljø, jf bilag 7.3 punkt 5.6
Service Request | Aktivering, reset og nedlukning af Supplerende Testmiljø |
Kort beskrivelse | Leverandøren skal ved bestillingen af denne standardydelse klargøre et driftsmiljø til uddannelses- og afprøvningsaktiviteter. Når KOMBIT har bestilt denne standardydelse, skal Leverandøren levere følgende Ydelser: • Leverandøren skal aktivere testmiljøet • Leverandøren skal efter anvisning af KOMBIT tage snapshot af miljøet jf. punkt 16. Denne ydelse skal også være anvendelig på andre testmiljøer • Leverandøren skal efter anvisning af KOMBIT nulstille testmiljøet og indlæse testdata til, at testmiljøet er anvendeligt til uddannelses- og testformål. Denne ydelse skal også være anvendelig på andre testmiljøer • Leverandøren skal efter aftale med KOMBIT nedlukke testmiljøet. |
Service Request | Aktivering, reset og nedlukning af Supplerende Testmiljø |
I perioder hvor der pågår specificerede uddannelsesaktiviteter skal servicemål være de samme som for Produktionsmiljøet fsva. Incident Management, jf. punkt 7. I andre perioder skal Servicemål være de samme som for Præproduktionsmiljøet, jf. bilag 7.1 Det skal være muligt for kommunerne at anvende testmiljøet fra kommunernes IT- miljø, kommunerne kursusudbydere eller fra en af KOMBIT anvist lokation, som er kompatibel hermed. Efter første aktivering af testmiljøet skal Leverandøren udføre og bestå en installationstest, jf. bilag 6. | |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 1 Arbejdsdag • Løsningstid aktivering: 5 Arbejdsdage • Løsningstid for nulstilling/reset: 5 Arbejdsdage • Løsningstid nedlukning: 5 Arbejdsdage • Løsningstid Førstegangs Etablering: 4 uger |
10.2.5 Ekstra testmiljø, jf bilag 7.3 punkt 5.7
Service Request | Opsætning af Ekstra testmiljø |
Kort beskrivelse | Leverandøren skal ved bestillingen af denne standardydelse klargøre et driftsmiljø til Leverandørens sprint testaktiviteter og øvrige aktiviteter som eksempelvis konverteringsforberedelser. Når KOMBIT har bestilt denne standardydelse, skal Leverandøren levere følgende Ydelser: • Leverandøren skal opsætte og vedligeholde et ekstra testmiljø, som skal anvendes til afprøvning af Systemet, jf. bilag 6 • Leverandøren skal installere nødvendigt programmel til anvendelse af Systemet i testmiljøet • Leverandøren skal oprette Brugere/testbruger med adgang adgang til Systemet i testmiljøet • Leverandøren skal efter aftale med KOMBIT nedtage testmiljøet, herunder slette data. • Leverandøren skal alene redegøre for at testmiljøet er tilgængeligt Der gælder ikke andre Servicemål end rapportering på miljøets anvendelse, hvorfor der ikke ydes løbende vederlag. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid opsætning: 15 Arbejdsdage • Løsningstid nedtagning: 5 Arbejdsdage |
10.2.6 Udarbejdelse af overdragelsesplan for Infrastrukturdrift
Service Request | Udarbejdelse af overdragelsesplan for overdragelse til Infrastrukturdrift jf. punkt 27 |
Kort beskrivelse | Leverandøren skal jf. punkt 27 udarbejde et udkast til en overdragelsesplan for fremtidig ovedragelse af Infrastrukturdriften af Systemet til tredjemand jf Driftskontraktens punkt 30 |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 25 dage |
10.2.7 Udarbejdelse af overdragelsesplan for Infrastrukturdrift og Applikationsdrift
Service Request | |
Kort beskrivelse | Leverandøren skal jf. punkt 29 udarbejde et udkast til en overdragelsesplan for fremtidig ovedragelse af Infrastrukturdriften og Applikationsdriften af Systemet til tredjemand jf Drifstkontraktens punkt 30 |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 25 dage |
Service Request | Overdragelsestest |
Kort beskrivelse | Leverandøren skal gennemføre en overdragelsestest, jf. punkt 27 og punkt 29. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 5 Arbejdsdage • Løsningstid: 90 dage |
Service Request | Databaseudtræk |
Kort beskrivelse | KOMBIT og kommunerne skal kunne bestille et special dataudtræk fra Systemet. Data skal leveres i et læsbart format. |
Pris | Særskilt betalbar ydelse, jf. bilag 7.2 |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid: 5 Arbejdsdage |
Service Request | Centraladministration |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse varetage Systemets centraladministration herunder test, dokumentation og deployment af foretagne ændringer. |
Pris | Særskilt betalbar ydelse, som timebaseret vederlag |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid: 5 Arbejdsdage |
10.2.11 Konfigurationsændringer
Service Request | Konfigurationsændring |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse foretage bestilte konfigurationsændringer herunder test, dokumentation og deployment af foretagne ændringer. |
Pris | Særskilt betalbar ydelse, som timebaseret vederlag |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid: 5 Arbejdsdage |
Service Request | Tekstændringer |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse foretage bestilte tekstændringer herunder test, dokumentation og deployment af foretagne ændringer. |
Pris | Særskilt betalbar ydelse, som timebaseret vederlag |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid: 5 Arbejdsdage |
10.2.13 Opdatering af skabelon
Service Request | Skabelon |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse oprette eller opdatere en eksisterende standardskabelon. Standardydelsen inkluderer test, dokumentation og deployment af foretagne ændringer. |
Pris | Særskilt betalbar ydelse, som timebaseret vederlag |
Servicemål | • Reaktionstid: 3 Arbejdsdage • Løsningstid ved oprettelse af ny skabelon: 15 Arbejdsdage |
• Løsningstid ved opdatering af eksisterende skabelon: 5 Arbejdsdage |
Service Request | Indlæsning af standardtestdatasæt |
Kort beskrivelse | Leverandøren skal ved bestilling af denne standardydelse indlæse aftalte standardtestdatasæt. |
Pris | Særskilt betalbar ydelse, som timebaseret vederlag |
Servicemål | • Reaktionstid: 1 Arbejdsdag • Løsningstid: 3 Arbejdsdage |
10.3 Servicemål for Service Requests
Leverandørens ydelser omfatter Request Fulfilment ydelser med fastsatte Servicemål for reaktionstid og løsningstid. Leverandøren skal uden unødigt ophold registrere og håndtere Service 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 ekstra driftsmiljøer) er reaktionstiden dog tiden, som må gå fra bestilling, 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 bestilling af løbende ydelser (f.eks. bestilling af ekstraordinære Service Desk-ydelser) 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 ydelseskataloget, er kravet til løsningstid 3 Arbejdsdage.
Leverandøren skal levere udkast til et ydelseskatalog. Ydelseskataloget skal være udarbejdet og klar til godkendelse senest inden Driftsprøvens begyndelse. Ydelseskataloget kan udvides med nye og/eller ændrede Request Fulfilment ydelser samt dertilhørende Servicemål.
Leverandøren skal udarbejde og fremsende til KOMBIT en oversigt over månedens bestilte og leverede standard request, jf. bilag 7.5.
11 ACCESS MANAGEMENT
Leverandøren skal som en del af Access Management til Driftsmiljøet håndtere korrekte adgange og rettigheder. Adgange til Systemet og Driftsmiljøet skal altid tildeles med udgangspunkt i ”need-to-know”/ ”need-to-have” og ”least privilege”-principperne, så det tilsikres, at adgange er tildelt brugere med et arbejdsbetinget behov. Der henvises til punkt 25 og Driftskontraktens punkt 13 om sikkerhedskrav, som i alle omstændigheder skal overholdes.
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, opdatere 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
• Administrere adgange til testmiljøer, herunder det Eksterne Testmiljø, for myndigheder og leverandører. Dette omfatter brugeroprettelse, tildele/fjerne rettigheder og password politik
• Udførelse af halvårlige review af tildelte rettigheder og distribuering af rapporten til KOMBIT
12 SERVICEMÅL FOR DRIFT
[Punkt 12 med underpunkter udgør et 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.3, herunder sikre korrekt eksekvering 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.5.
Servicemål for driftsafvikling som beskrevet i punkt 12 og underpunkter er opdelt i Servicemål for Applikationsdrift, jf. punkt 12.1, Servicemål for Infrastrukturdrift, jf. 12.2, en opgørelse af Kombineret Tilgængeligheds Servicemål, jf. punkt 12.3, en opgørelse af Systemets brugeroplevede driftseffektivitet, jf. punkt 12.4.
12.1 Servicemål for Applikationsdrift
12.1.1 Servicemål for driftseffektivitet for Applikationsdrift
Systemet og driftsmiljøerne skal driftsafvikles i Aftalt Åbningstid bortset fra, når der udføres ændringer i servicevinduer, jf. punkt 17.5, eller anden driftstid er aftalt, jf. bilag 7.3 punkt 5.1. Servicemålene for driftseffektiviteten er angivet i nedenstående Tabel 11: Oversigt over Servicemål for Applikationsdrift.
Applikationsdrift Servicemål for driftseffektivitet for Systemet per miljø | Måleperiode 1 | Måleperiode 2 |
Produktionsmiljøet | 99,0 | 95,0 |
Præproduktionsmiljøet | 95,0 | - |
Eksternt Testmiljø | 95,0 | - |
Supplerende Testmiljø | 95,0 | - |
Applikationsdrift Servicemål for driftseffektivitet for Systemet per miljø | Måleperiode 1 | Måleperiode 2 |
Internt Testmiljø | - | - |
Ekstra testmiljøer | - | - |
Tabel 11: Oversigt over Servicemål for Applikationsdrift
12.1.2 Måling af driftseffektivitet for Applikationsdrift
Driftseffektiviteten måles for Systemet som helhed og driftseffektivitetsprocenten opgøres således per miljø: Tilgængelig Driftstid x 100 %
Aftalt Driftstid
Ved ”Tilgængelig Driftstid” forstås, at hele Systemet kan anvendes til normal driftsafvikling herunder uden driftsforstyrrelser i form af prioritet A Incidents eller prioritet B Incidents, jf. punkt 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 13. Tidsrum med for lange svartider fragår i stedet i Tilgængelig Driftstid i overensstemmelse med det i punkt 13.7.3 anførte. Herudover fragår tidsrum i Tilgængelig Driftstid, hvor Leverandørens forhold indebærer en unødig forhaling af løsningen på et Incident, hvor Leverandø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 Incidents fratrækkes minimum 5 minutter i Tilgængelig Driftstid, idet al yderligere 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 Anvendersystemer eller i andre systemer, som Leverandøren ikke er ansvarlig for), eller 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 periode 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 det 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 driftsforstyrrelse 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 driftsforstyrrelse 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 driftsforstyrrelse 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 minutter + 38 minutter, i alt 158 minutter, dvs. der skal fragå 158 minutter i den Tilgængelige Driftstid.
Den "Aftalte Driftstid" i Måleperiode 1 er hele Måleperiode 1. Den "Aftalte Driftstid" i Måleperiode 2 er hele Måleperiode 2.
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 Leverandøren anvender mere tid til servicevinduet end aftalt, jf. servicevinduerne i punkt 17.5, fragå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 indberettes som en del af driftsrapporteringen, jf. bilag 7.5.
Driftseffektiviteten for Produktionsmiljøet måles og opgøres særskilt for henholdsvis a) Måleperiode 1 og b) Måleperiode 2. Driftseffektiviteten for øvrige driftsmiljøer måles og opgøres alene for Måleperiode 1.
12.2 Servicemål for Infrastrukturdrift
Nedenfor angives først Servicemål til driftseffektivitet, dernæst måling af driftseffektivitet.
12.2.1 Servicemål for driftseffektivitet for Infrastrukturdrift
Systemet skal driftsafvikles i Aftalt Åbningstid bortset fra, når der udføres ændringer i servicevinduer, jf. punkt 17.5, eller anden driftstid er aftalt, jf. bilag 7.3 punkt 5.1. Servicemålene for driftseffektiviteten er angivet i nedenstående Tabel 11: Oversigt over Servicemål for Applikationsdrift.
Infrastrukturdrift Servicemål for driftseffektivitet per miljø | Måleperiode 1 | Måleperiode 2 |
Produktionsmiljøet | 99,0 | 95,0 |
Præproduktionsmiljøet | 95,0 | - |
Eksternt Testmiljø | 95,0 | - |
Supplerende Testmiljø | 95,0 | - |
Internt Testmiljø | - | - |
Ekstra testmiljøer | - | - |
Tabel 12: Servicemål for driftseffektivitet for Infrastrukturdrift
12.2.2 Måling af driftseffektivitet for Infrastrukturdrift
Driftseffektiviteten måles for Systemet som helhed for henholdsvis Produktionsmiljø, Præproduktionsmiljø 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 Leverandøren ikke eller kun delvis er ansvarlig for årsagen.
Der skal ved enhver driftsforstyrrelse i tilgængeligheden som følge af prioritet A Incidents eller prioritet B Incidents fratrækkes minimum 5 minutter i Tilgængelig Driftstid, idet al yderligere 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 Anvendersystemer 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 periode 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 det 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 et prioritet A eller prioritet B Incident, har befundet sig i en ikke-redundant tilstand, og Incidentet skyldes den ikke-redundante 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 Produktionsmiljøet.
Den "Aftalte Driftstid" i Måleperiode 1 er hele Måleperiode 1. Den "Aftalte Driftstid" i Måleperiode 2 er hele Måleperiode 2.
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 Leverandøren anvender mere tid til servicevinduet end aftalt, jf. servicevinduerne i punkt 17.5, fragå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 indberettes som en del af driftsrapporteringen, jf. bilag 7.5.
Driftseffektiviteten for Produktionsmiljøet måles og opgøres særskilt for henholdsvis a) Måleperiode 1 og b) Måleperiode 2. Driftseffektiviteten for øvrige driftsmiljøer måles og opgøres alene for Måleperiode 1.
12.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 punkt 9.
KTS omfatter et kombineret Infrastrukturdrift og Applikationsdrift Servicemål for den totale driftseffektivitet for Systemet på Produktionsmiljøet . KTS opgøres på følgende måde:
Måleperiode 1 for Produktionsmiljøet:
(Opgjort driftseffektivitet for Applikationsdrift i henhold til punkt 12.1.2 i % + opgjort driftseffektivitet for Infrastrukturdrift i henhold til punkt 12.2.2 i %) – 100 % = KTS i %.
Måleperiode 2 for Produktionsmiljøet:
(Opgjort driftseffektivitet for Applikationsdrift i henhold til punkt 12.1.2 i % + opgjort driftseffektivitet for Infrastrukturdrift i henhold til punkt 12.2.2 i %) – 100 % = KTS i %.
12.4 Systemets brugeroplevede driftseffektivitet
Leverandøren skal månedsvis opgøre og rapportere på Systemets brugeroplevede driftseffektivitet for Applikationsdrift og Infrastrukturdrift, både individuelt og samlet 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 Applikationsdrift og Infrastrukturdrift gælder, at samtidige tidsrum med driftsforstyrrelser for Applikationsdrift og Infrastrukturdrift ikke adderes.
13 SYSTEMETS SVARTIDER
[Punkt 13 med underpunkter udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
13.1 Generelt om svartider
Leverandøren skal foretage svartidsmålinger for funktionaliteten i Systemet, som den anvendes af Brugere, Anvendere og Anvendersystemer via grænseflader til Systemet og som den i øvrigt udføres af Systemet automatisk. Dette gælder for Produktionsmiljøet, samt i Eksternt Testmiljø og/eller Præproduktion når der gennemføres svartidsrelaterede Prøver
Svartidsmålingerne skal redegøre for, om der er væsentlige udsving i svartiderne for funktionalitet i Systemet. Formålet med Leverandørens svartidsmålinger er at måle og dokumentere, 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 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 skal udarbejde detaljeret redegørelse for svartidsmålingerne fremfor kun at opgøre gennemsnitsværdier af målingerne ift. de opsatte Servicemål.
Leverandøren har ansvaret for at sikre, at krav og Servicemål til alle svartider overholdes.
Eksempler på Svartider for transaktioner i brugergrænsefladen er angivet i Tabel 13. Eksempler på servicetransaktioner er angivet i Tabel 14
Leverandøren har i Systemdokumentationen angivet hvilke svartid målepunkter, som monitoreres. Svartid målepunkterne skal aftales med KOMBIT i Etape 2, og derefter holdes opdateret i forbindelse med implementering af ny funktionalitet
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:
• Svartider for funktionalitet udstillet via Systemets brugergrænseflader, jf. punkt 13.5.
• Svartider for funktionalitet udstillet via Systemets Eksterne Snitflader, jf. punkt 13.6.
Leverandøren skal som et led i Event Management løbende overvåge overholdelsen af Servicemål for svartider. Overvågningen skal baseres på målinger udført i 15 minutters-intervaller i Måleperiode 1 og 30 minutters-intervaller i Måleperiode 2.
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.
Svartidsmålingerne og opgørelse af målopfyldelse for svartid i punkt 13.7 baseres på månedens faktiske antal transaktioner i brugergrænsefladen og Servicetransaktioner i Eksterne Snitflader.
Manglende overholdelse af Servicemål for Ønskede eller Maksimale Svartider medfører:
• At Leverandøren skal oprette Incidents i henhold til punkt 13.2
• At der skal ske opgørelse af målopfyldelse for svartid samt eventuelt reduktion af Tilgængelig Driftstid i henhold til punkt 13.7
13.2 Oprettelse af Incidents
Leverandøren skal oprette et prioritet A Incident, hvis Servicemålet for Maksimale Svartider ikke er overholdt i et interval, samt oprette et prioritet B Incident, hvis Servicemålet for Ønskede Svartider ikke er overholdt i et interval.
I måleperiode 2 oprettes overskridelser af Servicemålet for Ønskede og Maksimale Svartider som prioritet D Incident. Leverandøren er dog forpligtet til uden ugrundet ophold at igangsætte de fornødne korrigerende indsatser for at sikre overholdelse af Servicemål for svartider.
Leverandøren skal altid oprette Incidents som beskrevet i punkt 7.3, hvis svartider har eller vil have indvirkning på Systemet og/eller løsningen af de opgaver, som Systemet anvendes til eller for.
Leverandøren skal endvidere oprette Incidents på anfordring fra KOMBIT eller en Anvender. Der oprettes ikke Incidents i friholdelsesperioderne, jf. punkt 13.7.1.
13.3 Modregning af svartid
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 brugeroplevede svartid som rapporteres jf. bilag 7.5.
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. Leverandøren er i sådanne tilfælde ansvarlig for at sikre, at den samlede målte svartid overholder Servicemålene for Ønskede og Maksimale Svartider.
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. Leverandø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 Anvendersystemleverandøren med henblik på at få afhjulpet forholdet.
For alle svartider gælder, at forsinkelser i Systemets svartider grundet forhold, som Leverandø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.
13.4 Måling af svartider
Med udgangspunkt i Tabel 13 og Tabel 14 aftales et antal ”Målepunkter”, som tilsammen udgør et repræsentativt billede af Systemets funktionalitet. Hvorvidt et Målepunkt er repræsentativt eller ej, skal kunne verificeres ved efterfølgende brug af data fra relevante logs.
Leverandøren skal indenfor måleperioderne (jf. punkt 2.3) med maksimalt 5 minutters interval udføre målinger af svartider i Systemet. Såfremt der anvendes stikprøver skal disse udtages mindst hvert 5. minut på de aftalte målepunkter. En fuldstændig opgørelse over målingerne rapporteres på månedlig basis og vedlægges driftsrapporteringen.
Svartidsmålinger anvendes ved beregning af tid, der fragår i Tilgængelig Driftstid, jf. punkt 13.7.3.
Svartidsmålingerne skal være repræsentative i forhold til den reelle brug af Systemet. Målinger skal som udgangspunkt foretages enten som reelle brugertransaktioner eller fra en klient-PC uden for Driftsmiljøet, eller gennem en applikation, der kan udføre simulering af samme. Hvilken metode, som anvendes til svartidsmålinger og Målepunkter skal afklares mellem Parterne, idet Leverandøren skal dokumentere, at målepunkterne er repræsentative samt sikrer aftestning af alle områder af Systemet.
Svartidsmålinger skal senest være implementeret ved Leveranceprøven.
KOMBIT kan for egen regning bede en uvildig tredjepart med ekspertise indenfor performancemå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 afklaringsmø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 anbefalinger til ændringer af Målepunkternes udformning, skal Leverandøren implementere disse, såfremt KOMBIT ønsker dette.
Leverandøren skal anvende en passende detail-logning af svartider for samtlige Servicetransaktioner på Systemet. Detail-logs kan anvendes af Leverandøren til afklaring i tilfælde af eksempelvis Incidents eller ved udfald af svartidsmålinger, jf. punkt 13.7.3. Disse logs skal fremsendes til KOMBIT som en del af den månedlige driftsrapportering. Detail-logs skal leveres i et format, der er læsbart på en almindelig kontor-PC.
13.5 Svartider for transaktioner i brugergrænsefladen
13.5.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 behandling 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 opdatering 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 at afgive 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 brugergrænsefladen i Systemet.
13.5.2 Servicemål for svartider i brugergrænsefladen
Der er to niveauer af Servicemål for svartider, som skal overholdes; ønskede svartider (”Ønskede Svartider”) og maksimale svartider (”Maksimale Svartider”).
Det overordnede Servicemål for Ønskede Svartider er, at 98 % af alle svartidsmålinger for transaktioner i brugergrænsefladen skal overholde de specifikke Ønskede Svartider, mens det overordnede Servicemål for Maksimale Svartider er, at 99,9% af alle svartidsmålinger for transaktioner i brugergrænsefladen skal overholde de specifikke Maksimale Svartider.
Tabel 13 angiver de specifikke Ønskede Svartider og Maksimale Svartider for brugergrænsefladen samt eksempler på transaktioner. Fastlæggelse af systemets svartid målepunkter skal starte op som aktivitet i Etape 2 og skal være afsluttet inden Overtagelsesprøven.
Ønskede Svartider (sekunder) | Maksimale Svartider (sekunder) | Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1 |
3 sek | 5 sek | Fra login til fagportalen vises med tilladte funktioner |
Ønskede Svartider (sekunder) | Maksimale Svartider (sekunder) | Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1 |
2 sek | 4 sek | Præsentere egen opgaveliste |
2 sek | 4 sek | Præsentere teamets opgaveliste |
0,2 sek | 0,4 sek | Anvender der går fra et felt til det næste, skal man kunne taste inden for 0,2 sek |
20 sek | 60 sek | Visning af simple rapporter på skærmen |
1 sek | 2 sek | Åbning af ny funktion (faneblade eller menupunkt), eller går fra et skærmbillede til det næste |
3 sek | 5 sek | Visning af dokumentliste på sag |
3 sek | 5 sek | Åbning af dokument på sag |
1 sek | 3 sek | Gem dokument på sag (indtil bruger kan arbejde videre) |
1 sek | 3 sek | Oprette journalnotal |
3 sek | 5 sek | Danne journal for 1 sag (indtil bruger kan arbejde videre) |
2 sek | 4 sek | Fra søgning på CPR nummer til præsentation af pensionistoverblik på person, som eksisterer i Systemet |
2 sek | 4 sek | Søgning på sag ud fra CPR og KLE nr |
1 sek | 3 sek | Åbn ’Opret ny pensionssag’ |
2 sek | 4 sek | Åbning af sag fra liste |
1 sek | 3 sek | Gem/opdater sag (indtil bruger kan arbejde videre) |
2 sek | 4 sek | Oprettelse af heldbredskort |
3 sek | 5 sek | Visning/Præsentation af refusionskrav |
Tabel 13: Ønskede og Maksimale Svartider på brugergrænsefladen
13.6 Svartider for automatiserede Servicetransaktioner og Eksterne Snitflader
13.6.1 Servicetransaktioner og Servicetransaktioners svartider
Systemets Eksterne Snitflader udstilles af en række services i Systemet. Hver Ekstern Snitflade har et antal snitfladeoperationer, som kan tilgås og aktiveres af Anvendersystemer.
En Servicetransaktion betyder andre it-systemers anvendelse af Systemets Eksterne Snitflader ved fremsendelse eller modtagelse af én samlet forespørgsel/opdatering.
Ved svartiden for en Servicetransaktion forstås tidsintervallet, fra Systemet modtager en besked fra et Anvendersystem, til behandlingen af beskeden i Systemet 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 eksekvering af de af Anvendersystemet kaldte snitfladeoperationer være en Servicetransaktion.
Ved eksekvering af automatiserede funktioner i Systemet forstås svartiden for en Servicetransaktion, som tidsintervallet fra den automatiserede funktion påbegyndes, til den automatiserede funktion er fuldt afsluttet, og Systemet er fuldt opdateret.
Det er KOMBIT, som i samarbejde med Leverandøren, fastlægger svartider på Systemet Servicetransaktioner og Eksterne Snitflader. I tilfælde af uenighed er det KOMBIT, som bestemmer.
13.6.2 Servicemål for svartider for Servicetransaktioner
Der er to niveauer af Servicemål for svartider, som skal overholdes; ønskede svartider (”Ønskede Svartider”) og maksimale svartider (”Maksimale Svartider”).
Det overordnede Servicemål for Ønskede Svartider er, at 98 % af alle svartidsmålinger for Servicetransaktioner skal overholde de specifikke Ønskede Svartider, mens det overordnede Servicemål for Maksimale Svartider er, at 99,9% af alle svartidsmålinger for Servicetransaktioner skal overholde de specifikke Maksimale Svartider.
Under dette punkt angives Servicemål for eksekveringstider for Systemets automatiserede funktioner til sagsprocessen.
Leverandøren har i Systemdokumentationen angivet kompleksiteten for hver automatiseret funktion til sagsprocessen. Såfremt en automatiseret funktions kompleksitet ikke er dokumenteret i Systemdokumentationen, som er godkendt af KOMBIT, vil KOMBIT foretage et konkret skøn ud fra de nedenstående definitioner og eksempler.
Der er to typer Servicemål for eksekveringstider, som skal overholdes; ønskede eksekveringstider hhv. maksimale eksekveringstider. De ønskede eksekveringstider (”Ønskede Eksekveringstider” i Tabel 14) er et Servicemål, som 95 % af alle målinger skal overholde, mens de maksimale eksekveringstider (”Maksimale Eksekveringstider” i Tabel 14) skal overholdes i 99,9 % af alle målinger.
Servicemål for eksekveringstider for Systemets automatiserede funktioner til sagsprocessen er angivet i følgende Tabel 14:
Ønskede Svartider (sekunder) | Maksimale Svartider (sekunder) | Eksempler og/eller eventuel henvisning til use case nummer i bilag 2.1 |
0,5 sek | 3 sek | Opret ny folkepensionist, som hentes fra UDK |
0,5 sek | 3 sek | Dan kvittering i form af Helbredskort |
5 ms | 15 ms | Gennemløb use case U-21, Vedligehold sag – Hændelse fra UDK’s pensionssystem, for en borger |
25 ms | 70 ms | Fastsættelse af finansieringskommune |
Tabel 14: Ønskede og Maksimale Svartider for automatiserede funktioner til sagsprocessen
Der gælder, at såfremt en Servicetransaktion har et input eller et output, der overstiger 5 MB, så øges Servicemå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 Anvendersystemet, jf. også punkt 13.6.1.
13.7 Opgørelse af målopfyldelse for svartid
I forbindelse med Leverandørens normale drift og vedligeholdelse af Systemet vil der kunne opstå kortere perioder, hvor Systemet er tilgængeligt, men hvor Leverandøren ikke vil kunne overholde Servicemål for svartider. Eksempler herpå er tidsrummet lige efter genstart af applikations- og databaseservere eller perioder, hvor der afvikles reorganisering eller batchjobs med høj belastningsprofil.
Leverandøren kan efter forudgående aftale med og godkendelse af KOMBIT udelade sådanne perioder – herefter benævnt friholdelsesperioderne - i beregningen af målopfyldelse for svartid. Det påhviler Leverandøren at tilsikre den nødvendige opsætning af miljøerne, herunder software, samt at sådanne aktiviteter tilrettelægges og placeres således, at påvirkningen af Anvenderne i friholdelsesperioderne minimeres mest muligt.
13.7.2 Beregning af målopfyldelse
Beregning af målopfyldelse baseres på det sammenlagte faktiske antal transaktioner i brugergrænsefladen samt Servicetransaktioner .
Transaktioner i perioder, hvor der er åbne prioritet A eller B Incidents, indgår ikke i beregningen for at undgå dobbelt fradrag i Tilgængelig Driftstid. Transaktioner i friholdelsesperioderne, jf. punkt 13.7.1, indgår heller ikke i beregningen.
Målopfyldelsen for Ønskede Svartider per måleperiode beregnes som:
𝑅𝑜 = (1 − 𝐸ø𝑜) ∗ 100, hvor
𝐸𝑡
Ro = Målopfyldelsen for Ønskede Svartider
Eøo = Antal transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader, hvor den Ønskede Svartid er overskredet
Et = Det totale antal transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader
Hvis Servicemålet for Maksimale Svartider ikke er overholdt, fratrækkes de transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader, hvor den Maksimale Svartid er overskredet, i Eøo. Dette sker for at undgå, at Leverandøren ifalder dobbelt nedetid for samme hændelse.
Hvis Servicemålet for Maksimale Svartider er overholdt, medregnes de transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader, hvor den Maksimale Svartid er overskredet, i Eøo.
Målopfyldelsen for Xxxxxxxxx Xxxxxxxxx per måleperiode beregnes som:
𝑅𝑚 = (1 − 𝐸𝑚𝑜) ∗ 100, hvor
𝐸𝑡
Rm = Målopfyldelse for Xxxxxxxxx Xxxxxxxxx
Emo = Antal transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader, hvor den Maksimale Svartid er overskredet
Et = Det totale antal transaktioner i brugergrænsefladen og Servicetransaktioner i de Eksterne Snitflader
13.7.3 Reduktion af Tilgængelig Driftstid
Hvis den beregnede målopfyldelse i punkt 13.7.2, ikke overholder det overordnede Servicemål for Ønskede Svartider eller Maksimale Svartider i punkt 13.5.2 og punkt 13.6.2, skal der ske en reduktion af den Tilgængelige Driftstid for Applikationsdrift, som beregnes i punkt 12.1.2.
Da reduktionen påvirker driftseffektiviteten opgøres den på kalendermånedsbasis per måleperiode som følger:
Overskridelse af Ønskede Svartider:
𝑈𝑜 = (𝑆𝐿𝐴𝑜 − 𝑅𝑜) ∗ 𝐴𝑑 /100, hvor
Uo = Antal minutter, som fratrækkes i Tilgængelig Driftstid pga. overskridelse af Servicemål for Ønskede Svartider
Overskridelse af Xxxxxxxxx Xxxxxxxxx:
𝑈𝑚 = (𝑆𝐿𝐴𝑚 − 𝑅𝑚) ∗ 𝐴𝑑 /100, hvor
Um = Antal minutter, som fratrækkes i Tilgængelig Driftstid pga. overskridelse af Servicemål for Maksimale Svartider
Der rundes op til nærmeste hele minut.
Eksempel 1:
Det overordnede Servicemål for Ønskede Svartider udgør 95%, og det overordnede Servicemål for Maksimale Svartider udgør på 99,9%. Den aftalte driftstid i Måleperiode 1 andrager 15.840 minutter.
Det samlede antal transaktioner i brugergrænsefladen og Servicetransaktioner i Eksterne Snitflader uden for friholdelsesperioden udgør 1.001.121 i Måleperiode 1. Der var et prioritet B Incident i Måleperiode 1. I incidentets varighed var der 1.121 transaktioner. Disse indgår ikke i beregning af målopfyldelsen.
Der indgår således 1.000.000 transaktioner i månedens beregning af målopfyldelsen for Måleperiode 1.
2.000 transaktioner overholdt ikke Servicemålet for Maksimale Svartider. Målopfyldelsen for Maksimale Svartider udgør:
1 - (2.000 / 1.000.000) * 100 = 99,8%.
Servicemålet for Maksimale Svartider på 99,9% er således overskredet med 0,1 procentpoint. Reduktion af Tilgængelig Driftstid udgør:
(99,9 – 99,8) * 15.840 / 100 = 15,84 minutter, som rundes op til nærmeste hele minut, dvs. 16 minutter.
52.000 transaktioner overholdt ikke Servicemålet for Ønskede Svartider. Heraf modregnes de 2.000 transaktioner, som førte til overskridelse af Servicemålet for Maksimale Svartider.
Målopfyldelsen for Ønskede Svartider udgør:
1 – ((52.000 - 2.000) / 1.000.000)) * 100 = 95%.
Servicemålet for Ønskede Svartider på 95% er således opfyldt. Der foretages ikke reduktion af Tilgængelig Driftstid.
Den samlede reduktion af Tilgængelig Driftstid i Måleperiode 1 som følge af svartidsoverskridelser udgør derfor 16 minutter.
Eksempel 2:
Servicemålet for Ønskede Svartider udgør 95%, og Servicemålet for Maksimale Svartider udgør 99,9%. Den aftalte driftstid i Måleperiode 1 andrager 15.840 minutter.
Det samlede antal transaktioner i brugergrænsefladen og Servicetransaktioner i Eksterne Snitflader uden for friholdelsesperioden udgør 1.001.121 i Måleperiode 1.
Der var et prioritet B Incident i Måleperiode 1. I Incidentets varighed var der 1.121 transaktioner. Disse indgår ikke i beregning af målopfyldelsen.
Der indgår således 1.000.000 transaktioner i månedens beregning af målopfyldelsen for Måleperiode 1.
1.000 transaktioner overholdt ikke Servicemålet for Maksimale Svartider. Målopfyldelsen for Maksimale Svartider udgør:
1 - (1.000 / 1.000.000) * 100 = 99,9%
Servicemålet for Maksimale Svartider på 99,9% er således opfyldt. Der foretages ikke reduktion af Tilgængelig Driftstid.
52.000 transaktioner overholdt ikke Servicemålet for Ønskede Svartider. Da Servicemålet for Maksimale Svartider er overholdt, indgår de 1.000 transaktioner, som overskred Servicemålet for Maksimale Svartider, ved beregning af målopfyldelsen for Ønskede Svartider.
Målopfyldelsen for Ønskede Svartider udgør:
1 – (52.000 / 1.000.000) * 100 = 94,8%
Servicemålet for Ønskede Svartider på 95% er således overskredet med 0,2 procentpoint. Reduktion af Tilgængelig Driftstid udgør:
(95-94,8) * 15.840 / 100 = 31,68 minutter, som rundes op til nærmeste hele minut, dvs. 32 minutter.
Den samlede reduktion af Tilgængelig Driftstid i Målerperiode 1 som følge af svartidsoverskridelser udgør derfor 32 minutter.
13.8 Brugeroplevede svartider
For at kunne sikre den gode brugeroplevelse, skal Leverandøren etablere målinger på relevante klienter og klienttyper. Disse målinger skal som minimum være repræsentative for anvendelsen af Systemet samt forbindelseskvalitet og skal anvendes både som dokumentation for brugeroplevelsen samt anvendes i dagligdagen af Leverandøren med henblik på fejlsøgning og optimering.
KAPITEL III SERVICE TRANSITION
14 INTRODUKTION TIL SERVICE TRANSITION
Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leverandø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 17, og til gennemførelse som Changes via Change Management, jf.
punkt 15. 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 Driftsmiljøet med Emergency Changes via Change Management, jf. punkt 15. 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 Patches via Patch Management, jf. punkt 18, og Change Management, jf. punkt 15.
• Test i forbindelse med opdatering af Systemet eller Infrastrukturen, jf. punkt 16.
• Planlægning af fremtidige nye Versioner, herunder både Major Version og Minor Version, til planmæssige opdateringer af Systemet, jf. punkt 17.6.
• Opbevaring af samt registrering af information om alle elementer for Systemet og Infrastrukturen og elementer i central database via Asset- og Configuration Management, jf. punkt 19.
• Vidensdeling med alle Interessenter i forbindelse med Service Transition via Knowledge Management, jf. punkt 20.
15 CHANGE MANAGEMENT
15.1 Generelle krav til 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 Produktionsmiljøet.
Ændringer til Systemet der ikke sker som en del af Leverandørens vedligeholdelsespligter i henhold til Driftskontrakten, sker som udvikling i henhold til Kontrakten. Når sådanne ændringer er klar til levering i form af en Implementeringspakke, implementeres de i Systemet i overensstemmelse med den aftale, der er indgået i medfør af Kontrakten, og under Change Management processen beskrevet under dette punkt 15.
Leverandøren skal med Change Management processen sikre, at alle ændringer, der skal foretages til Systemet samt ændringer til selve Produktionsmiljøet, håndteres som Changes efter faste og veldefinerede rutiner med fokus på bl.a. risikominimering, kvalitetssikring og forretningsmæ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, Anvendersystemleverandører, Integrationsleverandør eller Tredjepartsprogrammelleverandør.
Changes/ændringer bestilles som Change Management via en Request for Change (RfC). Alle ændringer skal udvikles og afprøves jf hhv. bilag 14 og bilag 6. RfC’en oprettes i Leverandørens IT Service Management system og behandles herefter i Change Advisory Board, jf. bilag 8.
Leverandøren skal honorere KOMBITs rimelige ønsker til tidsplan for gennemførelse af Changes med henblik på at understøtte effektiv driftsafvikling og planmæssig videreudvikling af Systemet.
Leverandørens Ydelser i forbindelse med Change Management er som følger:
• Initiere Change Management processen baseret på en modtaget RfC, uanset om RfC’en hidrører fra Leverandørens organisation eller KOMBITs organisation
• Prioritering og vurdering af den fremsendte RfC i forhold til gennemførelse, herunder risikovurdering, jf. punkt 15.3
• Dokumentation af alle Changes, jf. punkt 15.4
• Forberedelse til samt gennemførelse af RfC’ens behandling i Change Advisory Board, jf. bilag 7.5, i forbindelse med KOMBITs stillingtagen til godkendelse
• Forberedelse til samt gennemførelse af hastebehandling for Emergency Change
• Modtage og behandle RfC fra Anvendersystemleverandører, Integrationsleverandører, Tredjepartsprogrammelleverandører samt KOMBIT
• Løbende orientering af indberetteren af RfC, om status, herunder i forbindelse med afvisning eller godkendelse i Change Advisory Board
• Orientering af Interessenter om kommende, udestående og afsluttede Changes. Dette omfatter kommunikation ved hjælp af mail og/eller Systemets hjemmeside
• Planlægning og gennemførelse af idriftsættelse af RfC
• Kvalitetssikring af gennemført RfC, herunder tilbagerulning til tilstanden før gennemførelsen i tilfælde af mislykket gennemførelse
• Gennemføre Standard Changes i overensstemmelse med Parternes aftaler herom
• Sikre at relevante tests gennemføres inden implementering samt gennemfø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 overensstemmelse 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.
15.1.1 Procedure for behandling af Request for Changes
Leverandøren initierer i overensstemmelse med punkt 15 Change Management processen på baggrund af modtagne RfC’er, således at CAB har det fornødne beslutningsgrundlag i forhold til at vurdere og behandle RfC’er, herunder ved at udarbejde og fremsende dokumentation af RfC i overensstemmelse med bilag 7.2.
På baggrund af Leverandørens dokumentation af RfC’er, træffer CAB beslutning om, hvorvidt en ændring/Change skal gennemføres, herunder om ændringen skal gennemføres og implementeres som en Standard Change. CAB er nærmere beskrevet i bilag 8 (Samarbejdsorganisation og rapportering)
For alle Changes gælder følgende:
• Ved uenighed om en Change’s driftsmæssige konsekvenser, øvrige konsekvenser eller risikovurdering kan hver af Parterne eskalere behandlingen af Changen til driftsgruppen.
• KOMBIT er berettiget til at afvise en Change, såfremt én eller flere af følgende kriterier er opfyldt:
o Leverandøren ikke har godtgjort, at Changen vil løse et Incident og/eller afhjælpe Fejl.
o Leverandøren ikke har godtgjort, at det er muligt at fastholde eller øge kvaliteten af Systemet og dens driftsafvikling efter Changens gennemførsel.
o Changen ikke er fyldestgørende dokumenteret og behandlet i overensstemmelse med bestemmelserne herom i punkt 15.
o Changen ikke er testet i tilstrækkeligt omfang til at give vished for resultatet af Changens gennemførelse, jf. punkt 16
o Changens rollback beskrivelse mangler eller er mangelfuld.
o KOMBIT kan over for Leverandøren sandsynliggøre, at Changen kan mindske kvaliteten af driftsydelsen, selvom denne gennemføres succesfuldt, herunder destabilisere eller forårsage nye Fejl.
• Hvis KOMBIT på baggrund af ovenstående afviser Changen, er Leverandøren uagtet dette forpligtet til at overholde Servicemål som specificeret i bilag 7.2.
• Hvis KOMBIT ønsker en Change gennemført trods saglige indsigelser fra Leverandøren, og Changen påviseligt øver betydende indflydelse på Systemets rette funktioner, er Leverandøren berettiget til med et skriftligt varsel på to (2) Arbejdsdage for fremtiden at kræve sig fritaget for sine forpligtelser i relation til de funktioner og/eller Ydelser, som påvirkes af Changen, i den udstrækning en sådan fritagelse er rimeligt begrundet. Genskabes den oprindelige situation, genopstår Leverandørens forpligtelser.
• Hvis Leverandøren ønsker en Change gennemført, og KOMBIT afviser Changen trods saglige begrundelser for Changen fra Leverandøren, og den manglende Change efterfølgende påviseligt medfører betydende indflydelse på Systemets rette funktioner, er Leverandøren berettiget til med et skriftligt varsel på to (2) Arbejdsdage for fremtiden at kræve sig fritaget for sine forpligtelser i relation til de funktioner og/eller Ydelser, som påvirkes af den manglende Change, i den udstrækning en sådan fritagelse er rimeligt begrundet. Gennemføres Changen efterfølgende i overensstemmelse med Leverandørens anbefalinger, genopstår Leverandørens forpligtelser.
• Der rapporteres i månedsrapporten, jf. bilag 7.5, på alle typer af Changes, inklusiv godkendte Changes, Emergency Changes, gennemførte Changes, som ikke er godkendte, samt fejlede Changes med tilhørende årsagsbeskrivelse.
• Leverandøren skal dokumentere alle Request for Changes (RfC), herunder gennemførte Changes og Standard Changes. Listen skal være elektronisk tilgængelig for KOMBIT på et projektsite eller lignende.
En Standard Change er forhåndsgodkendt af og beskrevet som sådan af CAB og kan efter forhåndsgodkendelsen gennemføres af Leverandøren uden yderligere behandling i CAB. Såfremt Standard Changen er beskrevet som en Change, der kan bestilles af KOMBIT eller andre Interessenter, er Leverandøren forpligtet til at gennemføre Standard Changen ved sådanne bestillinger.
Begge Parter kan komme med generelle forslag til Standard Changes, ligesom Parterne kan foreslå, at RfC’er skal implementeres som Standard Changes.
Forud for en beslutning om at implementere Standard Changes skal der udarbejdes en beskrivelse af de(n) pågældende Standard Change(s), herunder i forhold til indhold og procedure for gennemførelse.
Beskrivelsen udarbejdes af Leverandøren på et detaljeringsniveau, som sikrer, at der ikke efterfølgende er tvivl om, hvad der er omfattet som Standard Change, og hvordan Standard Changen skal udføres i praksis.
Beskrivelsen skal skriftligt godkendes af KOMBIT, som kan stille krav til ændringer i beskrivelsen af Standard Changen inden godkendelsen.
Leverandøren må ikke udføre en Change som en Standard Change, før KOMBIT har godkendt beskrivelsen af den pågældende Standard Change.
Når en Change er skriftligt godkendt som Standard Change af KOMBIT, vedlægges beskrivelsen af Standard Changen som underbilag til dette bilag, og skal efterfølgende gennemføres af Leverandøren i overensstemmelse med beskrivelsen.
Emergency Changes må kun gennemføres grundet et Prioritet A eller B Incident, eller grundet stor risiko for driftsforstyrrelser i nær fremtid, såfremt en Emergency Change ikke implementeres.
Emergency Changes skal så vidt muligt dokumenteres i henhold til retningslinjerne under punkt 15, inden implementering og behandles i CAB med henblik på KOMBITs godkendelse.
Fremgangsmåden kan dog afviges, såfremt dette er afgørende i forhold til at sikre formålet med gennemførelsen af en Emergency Change. Emergency Changes skal da forsøges godkendt hos KOMBIT via opkald til mobiltelefon samt SMS til KOMBITs driftschef inden implementering, men må implementeres uden KOMBITs godkendelse, såfremt KOMBITs driftschef ikke besvarer Leverandørens henvendelser.
Leverandøren skal snarest muligt orientere KOMBIT om Emergency Changes, der implementeres uden behandling i CAB, idet Leverandøren samtidig skal dokumentere den pågældende Emergency Change i henhold til bilag 7.2. KOMBIT kan herefter kræve den pågældende Emergency Change behandlet i CAB inden for tre (3) Arbejdsdage eller et af KOMBIT fastsat længere varsel.
15.2 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 planlagte gennemførelsestidspunkt, Systemet er opdateret i overensstemmelse med formålet med Changen, og Systemet i øvrigt opfylder Kontraktens krav, herunder til Servicemål.
15.3 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. Risikovurderingen skal som minimum omfatte stillingtagen til følgende:
• Hvor stor en indsats kræves for at gennemføre RfC’en, herunder behov for forberedelse, 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 tilbagerulningen skal indgå i vurderingen.
15.4 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, herunder plan for test- og verifikationsaktiviteter
• Hvilke Brugere, der berøres ved eventuelt forlænget servicevindue
• En risikovurdering efter retningslinjer i punkt 15.3
• En kategorisering af Changen som Standard Change, eller lav-risiko, mellem-risiko eller høj-risiko Change baseret på risikovurderingen
• En tilbagerulningsplan inklusiv sidste tidspunkt for beslutning om tilbagerulning, 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åbegyndelse, 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, driftsvejledninger mv.
• Eventuelle konsekvenser for Leverandørens Ydelser og overholdelse af Servicemål
• Eventuelle konsekvenser for supportsamarbejdet
16 VALIDATION OG TEST
Leverandøren skal sikre, at der i forbindelse med alle nye Versioner, jf. punkt 17, samt øvrige Changes, testes behørigt i overensstemmelse i henhold til systemets livscycklusmodel i bilag 14 og bilag 6.
Hvis Leverandørens ydelser vedrørende Changes tilvejebringes på grundlag af cloud standardydelser, anses cloud leverandørens standarddokumentation for test og validering for fyldestgørende.
• Leverandøren skal i måleperiode 1, samt øvrige tider, hvor der skal foregå test, sikre at testmiljøer og Præproduktionsmiljøet er anvendelige til testformål, herunder at eksempelvis programmel, testdata, konfiguration, fungerende 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 snapshots af driftsmiljøer. Et snapshot indeholder nødvendig information om Programmel, Konfigurationsmateriale og data i Systemet samt Driftsmiljøet, således at miljøet kan genetableres ud fra snapshots på et senere tidspunkt.
• Leverandøren skal underrette KOMBIT inden 14 Arbejdsdage, såfremt et snapshot bliver 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ørgslen 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 og Integrationsleverandører før genetableringen og Brugere. 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 forespørgslen.
På KOMBITS foranledning skal Leverandøren udføre etablere snapshot og genetableringe som en Service Request.
Leverandøren leverer følgende Ydelser til validering og test i relevant og nødvendigt omfang:
• Test af alle Patches i forbindelse med opdatering af Programmel/programmel i Systemet og Driftsmiljøet, jf. punkt 18.
• Test af alle nye Versioner af Tredjepartsprogrammel i overensstemmelse med bestemmelserne i bilag 6.
• Sikring af, at der før installation i Driftsmiljøet gennemføres tilstrækkelige tests til verifikation af, at fejlrettelserne er gennemført med succes. Det skal verificeres, at fejlrettelserne mv. løser de identificerede Incidents, Problems og/eller Fejl, samt at der ikke opstår nye Incidents, Problems og/eller Fejl eller utilstrækkelig performance. Systemets opdatering med fejlrettelserne mv. skal således kvalitetssikres i tilstrækkeligt omfang til at kunne levere fejlfri og stabil drift under overholdelse af alle Servicemål. Der skal i forbindelse med testen gennemføres 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 fejlrettelser, Changes og Patches til Systemet og Driftsmiljøet. Dokumentationen leveres som en del Systemdokumentation og driftsdokumentationen.
17 RELEASE AND DEPLOYMENT MANAGEMENT
Leverandøren skal vedligeholde Driftsmiljøet og Systemet. Krav til Leverandørens vedligeholdelse 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, medmindre andet aftales med KOMBIT:
• Vedligeholdelse af Systemet med nye Versioner af Programmel fra Leverandøren, jf. punkt 17.1
• Vedligeholdelse af Driftsmiljøet med nye Versioner af programmel, jf. punkt 17.1.
• Vedligeholdelse af Systemet med nye Versioner af Tredjepartsprogrammel, jf. punkt 17.2
• Vedligeholdelse af Integrationer, jf. punkt 17.3
• Vedligeholdelse af data, jf. punkt 17.4
• Planlægning af releases og sikring af sporbarhed i indholdet af releases til releasens enkeltdele, herunder udarbejdelse af releasenote, som dokumenterer indholdet af relasens enkeltdele
• Planlægning af nye Versioner, jf. punkt 17.6
• Sikring af koordination, involvering og styring af de relevante Interessenter, herunder Tredjepartsprogrammelleverandører, Anvendersystemleverandører, Integrationsleverandø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 at dokumentere dette overfor KOMBIT, herunder i forbindelse med en eventuel audit/kontrol.
Leverandøren skal endvidere gøre det muligt for KOMBIT at deltage som observatør ved gennemførelsen af Changes samt gøre det muligt for KOMBIT at 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 17.5.
17.1 Vedligeholdelse af Systemet og Driftsmiljøet med nye Versioner af Programmel/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 Systemet 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 fungere 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, applikationsserver eller lign. Det er KOMBITs ansvar at sikre det nødvendige aftaleforhold med Tredjepartsprogrammelleverandøren. Leverandøren skal efter behov sikre KOMBITs inddragelse i koordineringen med Tredjepartsprogrammelleverandører. I tilfælde af, at Tredjepartsprogrammelleverandøren ikke imødekommer anmodninger fra Leverandøren om at tilpasse Tredjepartsprogrammel, skal Leverandøren uden ugrundet ophold 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 8
En Version af en Integration eller Systemets Eksterne Snitflader kan kun nedtages eller ændres efter forudgående skriftlig aftale med KOMBIT.
Leverandøren leverer nye Versioner af programmel til Driftsmiljøet, når det krævet for at kunne driftsafvikle nye Versioner af Programmel til Systemet, og i øvrigt besluttet i CAB, jf. bilag 8.
Leverandøren orienterer uden ugrundet ophold KOMBIT samt øvrige Anvendere om nye Versioner, herunder om væsentlige ændringer i forhold til tidligere Versioner, når sådanne foreligger.
Leverandøren skal i forbindelse med nye Versioner af Systemet orientere KOMBIT om konsekvenserne ved at installere en ny Version, og ved ikke at installere en ny Version, herunder for Leverandørens overholdelse af Systemets Servicemål.
Hvis KOMBIT ønsker den nye Version af Systemet installeret, forestår Leverandøren sådan installation i Systemet samt Driftsmiljøet.
Leverandøren skal sikre, at nye Versioner Systemet og nye Versioner af programmel til Driftsmiljøet testes behørigt og i overensstemmelse med bestemmelserne herom, jf. bilag 6.
I forbindelse med videreudvikling og vedligehold af Systemet kan Parterne aftale en eventuel indkøringsperiode for den nye Major eller Minor Version. Indkøringsperioden kan anvendes i situationer, hvor der er brug for yderligere afprøvning, end der kan ske i testmiljøerne samt Præproduktionsmiljøet. I Indkøringsperioden vil Leverandøren ikke kunne ifalde bod for nedetid som følge af Incidents, hvis leverandøren kan dokumentere, at de er forårsaget af den konkrete nye Major eller Minor Version.
Leverandøren er på KOMBITs forlangende forpligtet til at foretage tilbagerulning til den tidligere version. Indkøringsperioden suspenderer ikke de i bilag 6 beskrevne Intern Test og Prøver.
Parterne aftaler nærmere om en eventuel indkøringsperiode, dens længde, tilbagerulningstid i tilfælde af driftsforstyrrelser, og evt. andre betingelser i aftalen, som dækker releasen.
Leverandøren skal herefter opdatere Systemet i Internt Testmiljø, Præproduktionsmiljøet, Eksternt Testmiljø og Produktionsmiljøet med de leverede nye Versioner af Programmel. Dette omfatter at installere de nye Versioner samt efter behov foretage koordinerede ændringer i konfigurationen af Systemet. Dette skal følge Change Management processen, jf. punkt 15.
[Resten af punkt 17.1 udgør et, som Tilbudsgiver ikke kan tage forbehold overfor].
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 anvendte standardprogrammel skal være under support. Hvis standardprogrammel udgår af support eller trækkes tilbage fra markedet, skal Leverandøren migrere til tilsvarende programmel, som skal godkendes forudgående af KOMBIT.
Det er Leverandørens ansvar at sikre, at ovenstående krav til versionering opfyldes.
17.2 Vedligeholdelse af Systemet med nye Versioner af Tredjepartsprogrammel
Leverandørens vedligeholdelse af Systemet omfatter at opdatere Systemet med nye Versioner af Tredjepartsprogrammel, der tidligere er idriftsat i Systemet. Dette skal ske i overensstemmelse med Driftskontraktens punkt 6 samt den vedligeholdelsesaftale, der er indgået mellem KOMBIT og Tredjepartsprogrammelleverandør.
Leverandøren skal sikre, at nye Versioner af Tredjepartsprogrammel testes behørigt og i overensstemmelse med bestemmelserne under punkt 16.
Leverandøren skal herefter opdatere Systemet i Produktionsmiljøet, Præproduktionsmiljøet og testmiljøerne med de leverede nye Versioner af Tredjepartsprogrammel. Dette omfatter at installere de nye Versioner samt efter behov foretage ændringer i konfigurationen af Systemet. Dette skal følge Change Management processen, jf. punkt 15.
17.3 Vedligeholdelse af Integrationer
Leverandøren har ansvar for at tage initiativ til at planlægge, koordinere og gennemføre opdateringer 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 Version 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 Tredjepartsprogrammelleverandø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 Leverandø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 Eksterne Snitflader.
En Version af en Integration eller Systemets Eksterne Snitflader kan kun nedtages eller ændres 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 Eksterne 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 konsekvensvurdering, risikovurdering samt en anbefalet prioritering i tilstrækkeligt omfang til, at KOMBIT 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 Snitflade til Systemet, via mail og Systemets hjemmeside om tidsplan for udfasning 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.
17.4 Sletning af data
Anvenderne skal rette henvendelse til KOMBIT, hvis de ønsker data, som de er (data)ansvarlige 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 vedligeholdelsesanmodning 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 anmodningen. KOMBIT skal i nødvendigt omfang bistå Leverandøren med at fastslå, hvilke data der skal slettes.
17.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.
17.5 Servicevinduer til vedligeholdelse
[Punkt 17.5 udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor].
Vedligeholdelsesarbejdet skal planlægges og udføres, så det er til mindst mulig gene for Brugerne. 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
Vedligeholdelsesarbejdet kan løbende udføres af Leverandøren, herunder uden for aftalte servicevinduer, så længe vedligeholdelsesarbejdet ikke medfører driftsforstyrrelser eller på anden måde gene for Brugerne.
Medmindre andet aftales med KOMBIT skal vedligeholdelsesarbejdet i Produktionsmiljøet, som medfører driftsforstyrrelser, risiko for driftsforstyrrelser eller på anden måde gene for Brugerne, finde sted i de servicevinduer, der fremgår af nedenstående. Der anvendes i denne forbindelse følgende begreber med den anførte betydning:
- Servicevindue betyder den periode, hvor vedligeholdelsen må finde sted.
- Varighed betyder den varighed, som vedligeholdelsen må have i det pågældende servicevindue.
- 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 varsel.
- Det er Leverandørens ansvar at sikre, at vedligeholdelsesarbejde, der foretages i servicevinduer, mindst muligt forstyrrer Brugernes anvendelse af Systemet. Medmindre andet skriftligt aftales med KOMBIT, skal Brugerne altid have adgang til Systemet, og vedligeholdelsesarbejdet skal tilrettelægges således, at det kun er enkelte dele af funktionaliteten, der påvirkes i forbindelse med et servicevindue.
Vedligeholdelsesarbejde skal ske i de servicevinduer, der fremgår af tabellen:
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 |
Tabel 15: Servicevinduer
Leverandøren kan ikke fastlægge servicevinduer i perioden 2 Arbejdsdage før og efter et månedsskift, medmindre dette aftales skriftligt med KOMBIT.
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 udskydelse 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, skriftligt meddele KOMBIT, såfremt Leverandøren mener, at en sådan ansvarsfritagelse finder anvendelse.
Leverandøren og KOMBIT kan i særlige tilfælde skriftligt aftale ekstraordinære servicevinduer.
17.6 Plan for nye Versioner
Leverandøren udarbejder i overensstemmelse med Driftskontraktens punkt 6.7 en Releaseplan for idriftsættelse af nye Versioner af Systemet. Planen skal opdateres løbende og KOMBIT skal orienteres ved ændringer.
18 PATCH MANAGEMENT
Patch Management processen gør det muligt for Leverandøren at levere opdateringer af Programmel i Systemet og programmel i Driftsmiljøet. Formålet med Patch er at rette fejl, samt afbøde sikkerhedsbrister og sikkerhedsrisici.
En Patch er en afgrænset opdatering af Programmel i Systemet, programmel i Infrastrukturen (f.eks. operativsystemer, switches, firewalls m.v.), firmware til udstyr og/eller Tredjepartsprogrammel.
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 kravene i den til enhver tid gældende persondatalovgivning.
• Leverandøren skal straks og uden unødigt ophold informere KOMBITs driftschef om identificerede sikkerhedsrisici.
• Leverandøren skal sikre, at gældende sikkerhedsrettelser, efter frigivelse, er testet og implementeret som Patch i henhold til Servicemålene i punkt 18.1.
• Leverandøren skal sikre og vedligeholde en service management procedure, der inkluderer en patchproces, og som indgår i Driftshåndbogen, jf. Bilag 7.4.
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 opdatering.
• Dokumentation, jf. bilag 4 og bilag 7.4, indeholdende overblik over installerede Patches samt publicerede, men endnu ikke installerede Patches.
Det er Leverandørens ansvar løbende at holde sig opdateret om og fremskaffe nye Patches til Standardprogrammel og programmel i Driftsmiljøet samt installere disse via Change Management processen.
Det er KOMBITs ansvar at sikre det nødvendige aftalegrundlag for, at Tredjepartsprogrammelleverandører orienterer Leverandøren om og leverer Patches til Tredjepartsprogrammel.
Installation af Patches skal følge Change Management processen, jf. punkt 15.
18.1 Servicemål for Patch Management
[Punkt 18.1 med underpunkter udgør et minimumskrav, som Tilbudsgiver ikke kan tage forbehold overfor.]
Nedenstående tabel beskriver installationsfristen, gældende for Patch af Programmel i Systemet og programmel i Driftsmiljøet, herunder infrastrukturkomponenter. Disse frister tilsidesætter ikke Servicemål for Incident Management i tilfælde af driftsforstyrrelser.
Patchtype | Installationsfrist | 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. persondatalovgivningen, eller eksekvering af kode uden advarsler eller prompter | Hurtigst muligt, dog senest inden 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 systemressourcer | 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 19: Servicemål for Patch Management
Installationsfristen beskriver den tid, der maksimalt må gå, før relevante Patches er installeret, 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 til enhver tid afvise et ønske fra Leverandø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øsning. Hvis der ikke kan opnås kontakt til KOMBITs driftschef, skal Leverandøren uden yderligere ophold udføre de nødvendige tiltag for at imødegå den sikkerhedsmæssige risiko.
Ved uenighed om kategorisering af patchtype afgøres tvisten i overensstemmelse med Driftskontraktens punkt 33.
I det omfang KOMBIT har behov for dokumentation for overholdelse af Servicemål for Patch Management, skal Leverandøren fremsende dokumentation herfor. Dokumentationen behøver ikke nødvendigvis bestå i udlevering af konkrete oplysninger om Patches, men kan fx bestå i, at en uvildig revisor bekræfter, at Servicemålene er overholdt.
18.1.1 Manglende opfyldelse af servicemål
Såfremt Leverandøren ikke overholder Servicemålet for patchtypen Kritisk Sikkerhedsmæssig 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 Sikkerhedsmæssig Patch, skal Leverandøren straks fremsende forslag til relevant Omgåelse af Incident til KOMBIT med henblik på KOMBITs godkendelse.
19 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 Management Database). Dette skal bl.a. omfatte programkode, Dokumentation, programscripts, konfigurationsfiler, licenser mv. Leverandøren skal sikre, at den centrale database er løbende opdateret, samt at adgangen til registrerede elementer eller information kan foregå uafhængig af enkeltpersoners tilgængelighed.
For ydelser, der leveres på grundlag af en public cloud baseret service, og hvor der ikke er adgang til oplysninger om servicens konfigurationsmæssige sammensætning, skal Leverandøren i stedet for foretage en beskrivelse af servicens snitflader og attributter i Configuration Management Databasen.
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 den til enhver tid gældende 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 konfigurationsoplysninger for systemet er korrekte og løbende opdateres, herunder at certifikater løbende opdateres i Systemet og i Driftsmiljø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 udløbsdato. Leverandøren skal dokumentere processer for, hvorledes certifikater håndteres. Dette omfatter bl.a. bestilling, udstedelse, opbevaring, opdatering og restriktiv adgang til især private nøgler.
Alle registreringer omfattet af dette punkt 19 skal udleveres i en let overskuelig og systematiseret oversigt årligt og ved Driftskontraktens ophør, jf. også Driftskontraktens punkt 31.3.
20 KNOWLEDGE MANAGEMENT
Knowledge Management omfatter at sikre, at alt relevant viden og information er tilgængelig 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 Ydelser.
Leverandøren skal sikre relevant og tilstrækkelig vidensdeling internt i Leverandørens organisation, med Underleverandører samt med alle andre Interessenter til Systemet og Infrastrukturen, 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:
• Vidensdeling med alle relevante Interessenter i forbindelse med væsentlige ændringer i organiseringen omkring Infrastrukturdrift, Applikationsdrift og Applikationsvedligehold.
• Vidensdeling med alle relevante Interessenter i forbindelse med Systemets 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.
• Vidensdeling med Systemets Brugere, Leverandørens drifts- og
supportpersonale, 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 anvendelsesmuligheder med ny Version mv.
KAPITEL IV SERVICE DESIGN
21 INTRODUKTION TIL SERVICE DESIGN
Nærværende kapitel indeholder bestemmelser for de Ydelser og Servicemål, som Leverandø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 22.
• Availability Management, jf. punkt 23.
• IT Service Continuity, jf. punkt 24.
• Information Security Management, jf. punkt 25.
• Supplier Management og Business Relations, jf. punkt 26.
• Overdragelsesplan og -test, jf. punkt 27 og 29.
• Deltagelse i overdragelse, jf. punkt 28 og 30.
22 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, I/O, transationer, netværk, database, bånd, mm. Målingerne af kapacitetsforbruget skal være så hyppige og af en sådan karakter, at det vil være muligt for Leverandøren rettidigt at spore selv mindre stigninger i forbrug, der kan fordre en udvidelse af kapacitet eller håndtering på anden vis.
Leverandøren skal kalenderkvartalsvis udarbejde kapacitetsopgørelser og -prognoser, som udover at tage udgangspunkt i en fremskrivning af de målte kapacitetsforbrug også inkluderer påvirkning af sæsonudsving og periodisk tilbagevendende aktiviteter samt generelle udviklingstrends og forretningsmæssige initiativer, eksempelvis installation af en ny Version eller indførelse af obligatorisk brug af Systemet. Leverandøren er forpligtet til på eget initiativ at holde sig orienteret om forventninger til Systemets fremtidige anvendelse ved dialog med KOMBIT samt nuværende og fremtidige Anvendere.
Det er Leverandørens ansvar, at kapacitetsprognoser inddrager og tager højde for eventuelle relevante målinger af kapacitetsforbrug på Underleverandørers hardware. Dette med henblik på rettidigt at kunne foretage de nødvendige ændringer, inden Incidents opstår på grund af kapacitetsmangel.
Leverandørens kvartalsvise kapacitetsopgørelser skal række mindst 12 måneder frem og skal leveres skriftligt til KOMBIT første Arbejdsdag i et kalenderkvartal, startende fra første kalenderkvartal efter beståelsen af Driftsprø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 alle historiske målinger af kapacitetsforbruget, og rapportere dette, såfremt KOMBIT anmoder herom.
23 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 Servicemå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 forbedringsmuligheder 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. Dog skal der løbende gennemføres risikoanalyse
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 kapacitet på hardware eller hardwarekomponenter i Driftsmiljøet.
24 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 en alvorlig eller kritisk Incident.
Leverandøren skal levere følgende Ydelser:
• Udarbejdelse og vedligeholdelse af Disaster Recovery plan, jf. punkt 24.1
• Planlægning og gennemførelse af årlig Disaster Recovery test, jf. punkt 24.2
• Skriftlig afrapportering af testens resultater til KOMBIT, jf. punkt 24.2 og 24.3
24.1 Disaster Recovery plan
Leverandøren skal udarbejde en detaljeret Disaster Recovery plan, som vedlægges Driftshåndbogen, når denne leveres til KOMBIT. Disaster Recovery planen skal bl.a. redegøre for, hvordan uforudsete Incident håndteres, så datatab og nedetid minimeres. Se endvidere punkt 24.2.
24.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 24.1 udarbejdede Disaster Recovery plan og skal overholde relevante Servicemål aftalt mellem Parterne inden gennemførelsen.
Scope for den årlige Disaster Recovery test udarbejdes inden testen i samarbejde med KOMBIT. 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 tilsvarende Disaster Recovery tests, der udføres på enkelte Anvendersystemer, som er væsentlig for værdien af en samlet Disaster Recovery test på tværs af systemerne. I dette tilfælde er Leverandøren forpligtet til at koordinere Disaster Recovery planen for og udførelsen af Disaster Recovery testen med Anvendersystemleverandørers tilsvarende 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 genetablering vil medføre en normal driftssituation for Systemet og de involverede Anvendersystemer.
Efter testens gennemførelse udarbejder Leverandøren på baggrund af testens resultater en rapport, som indeholder beskrivelser af opmærksomhedspunkter og problemstillinger, der kan forringe betingelserne for eller forhindre en succesfuld Disaster Recovery, samt handlingsplaner med henblik på at adressere de identificerede problemstillinger.
24.3 Disaster Recovery rapport
Rapporten for gennemført Disaster Recovery test skal være KOMBIT i hænde senest 10 Arbejdsdage 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 fremrykket til hurtigere implementering end de 90 Dage, efter aftale mellem KOMBIT og Leverandøren.
24.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 afprø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 Anvenderne 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åledes at det altid er de mest relevante komponenter som afprøves.
Afprøvningen skal dokumenteres 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 halve å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 over for 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 halve å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 normal drift i et af de fastlagte servicevinduer. Afprøvningen skal dokumenteres over for KOMBIT.
Hvis Leverandøren tilbyder et public cloud setup
Leverandøren skal senest 30 Dage efter godkendt Driftsprøve samt efterfølgende én gang hvert halve år gennemføre en afprøvning af tilgængelighed for de public cloud services, der anvendes 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 er relevant at teste Leverandørens konfiguration af de anvendte public cloud services og i særlige grad de teknikker og metoder, der anvendes til at skabe redundans for applikationer, databaser og netværkskommunikation. Hvis det er muligt at teste komponenter i den valgte public cloud leverandørs infrastruktur, skal sådanne test ligeledes gennemføres. Såfremt det ikke er muligt at teste, skal det på anden måde verificeres/dokumenteres, at redundans er sikret. 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 normal drift i et af de fastlagte servicevinduer. Afprøvningen skal dokumenteres over for KOMBIT.
25 INFORMATION SECURITY MANAGEMENT
Information Security Management omfatter at sikre planlægning, implementering, opretholdelse, 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 anvendeligt, 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 vedligeholde processer og arbejdsprocedurer, som sikrer overholdelsen af den gældende sikkerhedspolitik
• Foretagelse af løbende kontrol af, om sikkerhedspolitikken overholdes, bl.a. ved anvendelse af stikprøvekontroller. Hvis der konstateres utilstrækkelig overholdelse af sikkerhedspolitikken, skal Leverandøren på de identificerede problemer foretage korrigerende aktiviteter, der kan sikre, at sikkerhedspolitikken overholdes fremadrettet. Leverandøren skal sikre, at den fremadrettede kontrol verificerer, at de korrigerende aktiviteter har afhjulpet tidligere identificerede problemer
• Forhindring af Security Incidents, eksempelvis med effektiv adgangs- og rettighedskontrol 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 eller passwords til personer med verificeret, korrekt identitet
• Reducering af skadevirkningen af Security Incidents i Systemet og Infrastrukturen, herunder ved løbende Backup af data, jf. punkt 6
• Detektering af Security Incidents i Systemet og Infrastrukturen, så disse observeres så tidligt som muligt med henblik på hurtig iværksættelse af korrigerende handlinger, 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. Systemet skal inspicere så meget som muligt af den krypterede trafik. Systemet skal tillige kontinuerligt overvåge og inspicere alle relevante logs og genere relevante events.
• Leverandøren skal endvidere sørge for, at logdata sikres mod forvanskning fx ved kontinuerligt offload til særlig sikret opbevaringskilde.
• Modvirkning af den fortsatte skadevirkning af allerede indtrufne Security Incidents i Systemet og Infrastrukturen, eksempelvis med nedlukning af brugeradgang ved gentagne 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 Infrastrukturen, 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 implementere 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 forbedringer til sikkerheden
• Planlægning og gennemførsel af en penetrationstest mindst en gang årligt, jf. punkt 25.1
• Deltagelse i kontrol af Leverandørens overholdelse af Driftskontrakten, jf. Driftskontraktens punkt 18
25.1 Penetrationstest
Leverandøren skal planlægge og gennemføre en penetrationstest/sikkerhedstest, jf. bilag 6, mindst en gang årligt med henblik på at verificere, at Systemet og Driftsmiljøet er underlagt
tilstrækkelige sikkerhedsforanstaltninger.
Testen skal udføres af en på feltet anerkendt ekstern ekspert som godkendes af KOMBIT.
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. Penetrationstesten skal have et omfang og en dybde, som sikrer, at alle relevante områder er dækket tilstrækkeligt. Leverandøren skal som led i planlægning af penetrationstesten udarbejde et udkast til penetrationstestens omfang (scope), og forelægge dette til KOMBIT godkendelse.
Leverandøren skal sikre, at KOMBIT har mulighed for at tage stilling 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 gennemførte penetrationstest.
Som opfølgning på penetrationstesten skal Leverandøren implementere forbedringer til
sikkerheden omkring Systemet og Driftsmiljøet, så evt. identificerede svagheder i sikkerhedsniveauet eller identificerede Security Incidents adresseres.
25.2 Revisionserklæringer
Såfremt det ikke er sket på et tidligere tidspunkt, skal Leverandøren ved Driftskontraktens ikrafttræden levere en ISAE 3000 type 1 revisionserklæring eller tilsvarende til KOMBIT. Erklæringen skal overholde KOMBITs instruks til den pågældende revisionserklæring og omfatte Leverandørens og Underleverandørers overholdelse af persondatalovgivning og rets- eller administrativ praksis, der måtte supplere og/eller erstatte disse regler.
Leverandøren skal endvidere én gang årligt i Driftskontraktens løbetid levere en ISAE 3000 type 2 revisionserklæring eller tilsvarende til KOMBIT. Erklæringen skal overholde KOMBITs instruks til den pågældende revisionserklæring og omfatte Leverandørens og Underleverandørers overholdelse af persondatalovgivning og rets- eller administrativ praksis, der måtte supplere og/eller erstatte disse regler.
ISAE 3000 type 2 erklæringen kan være af generel karakter og omfatte alle Leverandørens kunder i det omfang, at ydelsen til KOMBIT falder ind under de generelle procedurer hos Leverandø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 overholdelse af persondatalovgivning m.m. 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 skal Leverandøren én gang i Driftskontraktens initiale 6-årige løbetid levere en systemspecifik erklæring (ISRS 4400 eller tilsvarende) til KOMBIT. Erklæringen skal overholde KOMBITs instruks til den pågældende revisionserklæring og omfatte Leverandørens overholdelse af Driftskontrakten.
Leveringstidspunktet aftales med KOMBIT.
Leverandørens revisionserklæringer skal dække Driftsmiljøet og Systemet samt eventuelle efterfølgende ændringer hertil. Leverandøren skal ligeledes indhente og fremsende en tilsvarende erklæring fra eventuelle Underleverandører, f.eks. driftsleverandører, som Leverandøren har indgået samarbejde med i forbindelse med varetagelse af opgaver for KOMBIT, i det omfang disse ikke er dækket af Leverandørens revisionserklæringer. Leverandøren skal sikre, at Underleverandører i relevant omfang bliver auditeret, samt at dette detaljeret indgår i revisionserklæringerne.
Erklæringerne skal i enhver henseende overholde KOMBITs gældende instrukser til revisionserklæringer. KOMBITs til enhver tid gældende instrukser findes på xxx.xxxxxx.xx/xxxxxxxxxxxxxxxxx. Leverandøren er forpligtet til at sikre, at instruksernes kontrolpunkter er omfattet af revisionserklæringerne, ligesom Leverandøren er forpligtet til at overholde alle ændringer til instrukserne. KOMBIT skal med rimeligt varsel orientere Leverandøren om ændringer til instrukserne samt efter forudgående drøftelse med Leverandøren fastsætte et rimeligt varsel for Leverandørens implementering af ændringer.
Såfremt Leverandøren kan dokumentere, at ændringen påfører Leverandøren omkostninger ud over de omkostninger, der er dækket af Leverandørens vederlag, skal Leverandøren fremsende estimat på meromkostningen til KOMBITs godkendelse. Leverandøren godtgøres disse meromkostninger ved en engangsbetaling fra KOMBIT, forudsat at KOMBIT har godkendt estimatet samt modtaget en specificeret faktura for de dokumenterbare meromkostninger, idet timebaserede ressourcer skal opgøres og afregnes som angivet i bilag 7.2.
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, fremsende 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 detaljerede revisionshandlinger, der er udført for at nå til erklæringens konklusioner. Er der afdækket risici og/eller svagheder hos Leverandøren og/eller Underleverandører, herunder i relation til overholdelse af KOMBITs sikkerhedspolitik, Driftskontrakten, persondatalovgivningen, ISO27001, Driftsmiljøet og/eller sikkerhedsprocedure, skal disse detaljeret fremgå af erklæringen.
Leverandøren afholder alle udgifter til ovennævnte erklæringer.
26 SUPPLIER MANAGEMENT OG BUSINESS RELATIONS
Leverandøren skal sikre, at kontrakter med Underleverandører samt interne aftaler i Leverandørens egen virksomhed understøtter Driftskontrakten på en måde, som sikrer, at Leverandøren kan leve op til sine forpligtelser i henhold til Driftskontrakten, herunder sikkerhedsmæssige krav.
Kontrakter med Underleverandører såvel som interne aftaler skal stilles til rådighed for KOMBIT 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.
27 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ø.
Leverandøren skal udarbejde udkast til overdragelsesplan på anmodning fra KOMBIT jf. punkt 10.2.6.
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 Driftsmiljø, 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ætninger, der er angivet under punkt 6 i bilag 7.3 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 installationsvejledninger og Konfigurationsmateriale. Leverandøren skal således demonstrere, at det til KOMBIT leverede materiale er tilstrækkeligt til at etablere Systemet til driftsafvikling i et andet driftsmiljø, jf. bilag 7.3.
Leverandøren rapporterer til KOMBIT om testresultatet senest 10 Arbejdsdage efter testens udførsel.
Såfremt Leverandøren ikke består testen skal Leverandøren uden særskilt betaling foretage nødvendige korrigerende handlinger og gentage testen til den bestås.
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.
Vederlaget for overdragelsestesten afregnes særskilt til den i bilag 7.2 angivne pris.
28 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 overensstemmelse med planen herfor, jf. punkt 27. KOMBIT sikrer, at der indgås aftale med tredjemand, 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 Infrastrukturdrift hos tredjemand i samarbejde med denne 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. Den pågældende tredjemand deltager og stiller ressourcer til rådighed i nødvendigt 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 omfang, således at tredjemand har en reel mulighed for at kunne levere en infrastrukturdriftsydelse, som lever op til Driftskontraktens bestemmelser.
Leverandøren skal efter overdragelsen af Systemet og data til Infrastrukturdrift hos tredjemand gennemføre en Driftsprøve. 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 overdragelsen af Systemet til Infrastrukturdrift hos tredjemand, jf. Driftskontraktens punkt 31.5.
29 PLAN FOR OG TEST AF SYSTEMETS OVERDRAGELSE AF INFRASTRUKTUR- OG APPLIKATIONSDRIFT
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ø.
Leverandøren skal udarbejde udkast til overdragelsesplan på anmodning fra KOMBIT, jf. punkt 10.2.7.
Planen for overdragelse af Infrastrukturdriften og Applikationsdrift skal modsvare den tilsvarende plan for overdragelse af Infrastrukturdriften, som Leverandøren udarbejder i overensstemmelse med ovenstående punkt 27.
Overdragelsesplanen skal have en kvalitet og opdateres som beskrevet i Driftskontraktens punkt 30.
Overdragelsesplanen for Infrastrukturdrift og Applikationsdrift skal forelægges for KOMBIT til godkendelse. Når overdragelsesplanen er godkendt af KOMBIT, skal denne vedlægges som underbilag til nærværende bilag.
KOMBIT kan med henblik på at sikre, at det er muligt at driftsafvikle Systemet i Andet Driftsmiljø, 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ætninger, der er angivet i punkt 4 i bilag 7.3 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 installationsvejledninger og Konfigurationsmateriale. Leverandøren skal således demonstrere, at det til KOMBIT leverede materiale er tilstrækkeligt til at etablere Systemet til driftsafvikling i et andet driftsmiljø, jf. bilag 7.3.
Leverandøren rapporterer til KOMBIT om testresultatet senest 10 Arbejdsdage efter testens udførsel.
Såfremt Leverandøren ikke består testen skal Leverandøren uden særskilt betaling foretage nødvendige korrigerende handlinger og gentage testen til den bestås.
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.
Vederlaget for overdragelsestesten afregnes særskilt til den i bilag 7.2 angivne pris.
30 DELTAGELSE I OVERDRAGELSE AF INFRASTRUKTUR- OG APPLIKATIONSDRIFT
Ved en eventuel opsigelse af Infrastrukturdriftsopgaverne og Applikationsdriftsopgaverne, forventes der fortsat drift, vedligeholdelse, support og videreudvikling af Systemet og Driftsmiljø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 herfor, jf. punkt 29. KOMBIT sikrer, at der indgås aftale med tredjemand, hvortil Systemet overdrages til Infrastruktur- og Applikationsdrift, om at samarbejde loyalt og aktivt med Leverandø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åledes at tredjemand har en reel mulighed for at kunne levere en infrastrukturdriftsydelse og applikationsdriftsydelse, som lever op til Driftskontraktens bestemmelser.
Leverandøren får dækket rimelige og dokumenteret tidsforbrug i forbindelse med overdragelsesopgaven, jf. Driftskontraktens punkt 31.5.