Bilag 7 Version 0.8 26-06-2015
INDHOLD 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 DEFINITIONER OG FORUDSÆTNINGER ANVENDT I DETTE BILAG... 5 3.1 NORMAL ARBEJDSTID... 5 3.2 KRITISK FORRETNINGSTID FOR SYSTEMET... 5 3.3 BATCH / AUTOMATISEREDE KØRSLER... 5 3.4 PEAK-SITUATIONER... 5 3.5 BACKUPPERIODER... 6 3.6 SERVICEVINDUER... 6 3.7 TRANSAKTIONER... 6 3.8 KAPACITET... 7 3.9 PRIORITERING AF INCIDENTS... 7 3.10 TILGÆNGELIGHED... 8 3.11 MÅLING OG RAPPORTERING AF SERVICEMÅL... 9 3.11.1 MÅLING AF SERVICEMÅL... 10 3.11.2 OPGØRELSE AF SERVICEMÅLSOPFYLDELSE VED BEGRÆNSET DATAGRUNDLAG... 10 3.11.3 MANGLENDE MÅLING OG/ELLER RAPPORTERING... 10 4 SERVICEMÅL... 11 4.1 GENERELLE SERVICEMÅL... 14 4.1.1 TILGÆNGELIGHED AF SYSTEMET... 14 4.1.2 SVARTIDER FOR SYSTEMET... 15 4.1.3 KRAV TIL SVARTID PER SVARTIDSTYPE... 17 4.2 SERVICEMÅL FOR LØBENDE DRIFT... 22 4.2.1 SERVICEMÅL VEDRØRENDE SERVICEDESK OG INCIDENT MANAGEMENT... 22 4.2.2 SERVICEMÅL VEDRØRENDE PROBLEM MANAGEMENT... 26 Bilag 7 Side 1 af 46 1
4.2.3 SERVICEMÅL VEDRØRENDE CHANGE MANAGEMENT... 27 4.2.4 SERVICEMÅL VEDRØRENDE RELEASE MANAGEMENT... 29 4.2.5 SERVICEMÅL VEDRØRENDE IT-SIKKERHED... 29 4.2.6 SERVICEMÅL VEDRØRENDE VALIDATION AND CONTROL... 32 4.2.7 SERVICEMÅL VEDRØRENDE DOKUMENTATION... 34 4.2.8 SERVICEMÅL VEDRØRENDE RAPPORTERING... 35 4.2.9 SERVICEMÅL VEDRØRENDE STANDARDSERVICEYDELSER... 36 4.2.10 SERVICEMÅL VEDRØRENDE DESKTOP MANAGEMENT... 36 4.3 SERVICEMÅL FOR VEDLIGEHOLDELSE OG VIDEREUDVIKLING AF SYSTEMET... 37 4.3.1 SERVICEMÅL VEDR. LØSNINGSTID IFM. FEJL OG MANGLER (APPLIKATION)... 37 4.3.2 DEFINITION AF ÆNDRINGSKATEGORIER... 38 4.3.3 SERVICEMÅL IFM. TILPASNINGER, VEDLIGEHOLD OG SUPPORT... 38 4.3.4 SERVICEMÅL VEDRØRENDE UDVIKLINGSPROJEKTER... 41 5 MODEL FOR OPGØRELSE OG AFREGNING AF BOD... 43 5.1 SPECIFIKATION AF BOD... 43 5.2 MAKSIMUMBOD... 43 5.3 BODSBEREGNING FOR SERVICEMÅL MED KPI... 43 5.4 EKSEMPEL PÅ BODSBEREGNING FOR SERVICEMÅL MED KPI... 45 5.5 ESKALATION I FORHOLD TIL PROAKTIVE BEFØJELSER... 45 6 PROCEDURER OG VÆRKTØJER... 46 Bilag 7 Side 2 af 46 2
1 Vejledning til Tilbudsgiver Bilaget skal udfyldes af Tilbudsgiveren, jf. nedenstående retningslinjer. Tilbudsgiver skal som del af sit tilbud følge og besvare instruktioner, som er markeret med [ ]. For nærværende bilag betyder det, at Tilbudsgiver skal indsætte en beskrivelse i punkt 6 af de generelle procedurer for måling og rapportering på overholdelse af samt de værktøjer, som Tilbudsgiver vil anvende til at understøtte dette arbejde. Tabel 1 Vejledning til Tilbudsgiver Bilag 7 Side 3 af 46 3
2 Indledning I dette bilag beskrives Kontraktens og bodsmodel. Bilaget træder i kraft på Overtagelsesdagen. og bodsmodel er knyttet til de løbende Ydelser efter Overtagelsesdagen. Formålet med bodsmodellen er at tilskynde Leverandøren til at levere ydelser af høj kvalitet. Udgangspunktet er, at ATP er mere interesseret i overholdelse af de aftalte end i at få en bod udbetalt. Derfor er den traditionelle model med bod for manglende overholdelse af suppleret med en model, som giver Leverandøren mulighed for at genvinde eventuel ifalden bod fra manglende overholdelse ved fremadrettet god performance. Derudover rummer modellen også eskalationsmekanismer, der træder i kraft, såfremt der i længere perioder er performance under det aftalte serviceniveau. Bilag 7 Side 4 af 46 4
3 Definitioner og forudsætninger anvendt i dette bilag 3.1 Normal Arbejdstid Normal Arbejdstid er alle Arbejdsdage fra kl. 08.00 16.00, jf. også definitionen i bilag 0 (Definitioner). 3.2 Kritisk Forretningstid for Systemet Kritisk Forretningstid for Systemet er alle Arbejdsdage fra kl. 06.00 til 22.00, men ATP forventer, at Systemet også er tilgængeligt i øvrig tid. Automatiserede kørsler forventes afviklet døgnet rundt alle årets dage i henhold til afviklingsplaner. 3.3 Batch / Automatiserede kørsler Batch processering/automatiske kørsler er afviklingen af et eller flere programmer (jobs) på en computer, uden interaktion med Brugere. Relevant styring skal kunne ske med prædefinerede parametre, uden manuel indgriben. 3.4 Peak-situationer Med peak menes situationer hvor belastningen på Systemet er højere end sædvaneligt. Boligstøttesystemets peak-situationer ligger i forbindelse med: Udbetaling af boligstøtte den første hverdag i måneden. Boligorganisationerne skal have oplysninger om udbetaling til deres lejere allerede midt i måneden. Ændring i beregningen på baggrund af eindkomst. Hvis en borger har fået for meget udbetalt, så sendes der en agterskrivelse til boligstøttemodtageren. Boligstøttemodtageren har herefter 8 dage til at indberette evt. indsigelser til afgørelsen pr. den 1. i næste måned. Dette giver stort pres på systemet. Dette sker hver måned. Studiestart. Antallet af modtagene boligstøtteansøgninger peaker i januar, august og september. Årsomregning i november måned med virkning fra 1. januar. I forbindelse med årsomregningen bliver alle sager opdateret med nye satser fra Social og integrationsministeriet. Det resulterer i, at samtlige boligstøttemodtagere modtager et brev fra Udbetaling Danmark Boligstøtte pr. 1. januar. Blandt andet derfor er januar måned kendetegnet ved en høj indberetningsprocent. Bilag 7 Side 5 af 46 5
Udsendelse af formueskema til boligstøttemodtagere. Formueskemaerne udsendes til modtagere af boligstøtte der bor i andelsbolig. Formuen skal registreres i systemet inden 1. marts. Efterreguleringskørslen omkring maj/juni. Når de fleste årsopgørelser er klar bliver de sammenlignet med de indkomstoplysninger, der har været oplyst til Systemet for husstanden. Efterregulering resulterer i, at der dannes enten krav eller udbetalinger til borgerne. I forbindelse med henvendelser om disse krav eller udbetalinger kan der forekomme store belastninger på systemet, når kunderådgiver skal kalde sagerne frem og rette oplysninger. Der er igen efterreguleringskørsel i september/oktober for de årsopgørelser, der ikke har været klar til efterreguleringskørslen i maj/juni. Diverse data udtræk til ATP, Danmarks Statistik, Ministeriet for Børn, Ligestilling, Integration og Sociale forhold (BLIS) og SKAT. Denne øgede belastning skal indgå i Leverandørens overvejelser vedrørende dimensioneringen af Boligstøttesystemet. 3.5 Backupperioder ATP forventer, at Systemet er tilgængeligt i de perioder, hvor der foretages backup, og accepterer ikke en lavere performance og eventuelt forøgede svartider i Kritisk Forretningstid jf. punkt 3.2. Backup skal gennemføres hele døgnet alle ugens dage. 3.6 Servicevinduer Et servicevindue er den tid, hvor Systemet kan være utilgængeligt, eller hvor der er en påvirkning af driften i forbindelse med vedligeholdelse og opdateringer efter nærmere aftale med ATP. Servicevinduer er placeret uden for Kritisk Forretningstid, jævnfør punkt 3.2 og bilag 2 (Situationsbeskrivelse). 3.7 Transaktioner Svartidsmålingerne for Systemet skal foretages på de transaktioner, som indgår i svartidsmålingerne for Overtagelsesprøven og Driftsprøven, jf. bilag 6 (Afprøvninger). Bilag 7 Side 6 af 46 6
3.8 Kapacitet Systemet skal med den driftskonfiguration, som Leverandøren har beskrevet i bilag 3B (Løsningsbeskrivelse) have kapacitet nok til at overholde alle i både en normal driftssituation og i peak-situationer. 3.9 Prioritering af Incidents Kategoriseringen af et Incident afhænger særligt af Impact og Urgency. Prioritet Definition Eksempler 1 Major (Kritisk) Ved kritiske Incidents forstås Incidents, der uanset årsag hindrer ATP s anvendelse af hele eller væsentlige dele af it-miljøet. ATP opfatter kategori 1 som major Incident, og en særlig funktion i ATP aktiveres til at håndtere major Incidents, i daglig tale kaldet Situation Management. Se beskrivelse vedr. ATP s proces for Situation Management i bilag 2 (Situationsbeskrivelse). Nedbrud på forretningskritisk system. Alle brugere i samme funktion / forretningsområde er forhindret i at udføre deres arbejde. Fejl med stor forretningskritisk konsekvens (f.eks. forsinkelse i udbetaling til borgere eller kritisk fejl i batchafvikling). Nedbrud på netværksforbindelser, herunder til tredjepart. Nærved fejl, der håndteres som prioritet 1, tæller ikke i nedetid. Eksempler på Nærved fejl med prioritet 1: Fejl, som skaber risiko for forsinkede udbetalinger til mange borgere. Fejl, som skaber risiko for fejl ved masseudsendelse af breve til borgere. IT-fejl, som skaber risiko for negativ offentlige mediers interesse af ATP / Udbetaling Danmark. Bilag 7 Side 7 af 46 7
Prioritet Definition Eksempler 2 Alvorlig Ved alvorlige Incidents forstås Incidents, som er til stor gene for mange af ATP s medarbejdere og/eller for mange borgere, som benytter den aftalte service. Alvorlige Incidents er Incidents, der uanset årsag hindrer ATP s anvendelse af dele af it-miljøet, Mere end 50 % af brugere i samme funktion / forretningsområder forhindret i at udføre deres arbejde. Overvågningssystemer viser manglende tilgængelighed eller svartider, der ikke overholder fastlagte osv. Udbetalingsfejl / forsinkelse som berører mængde af borgerne. Kritisk fejl i batchafvikling. 3 Normal 4 Minor En Incident, som er til gene for kunderådgivere eller borgere, men som evt. kan omgås via workaround indtil fejlen er rettet og / eller som ikke i væsentlig grad forsinker arbejdets udførelse. En Incident, som har minimal betydning, men som skal løses. Fejlens løsningstid aftales ml. ATP og Leverandør Nærved fejl, der håndteres som prioritet 2, tæller ikke i nedetid. En eller meget få borgere er berørt af den pågældende fejl uden større forretningsmæssig / økonomisk konsekvens. Fejl, som kun påvirker interne sagsbehandling for en eller få kunderådgivere. Fejl som ikke direkte påvirker sagsbehandling eller forretningsfunktionalitet for kunderådgivere / borgere. Tabel 2 Incidentkategorier 1-4 3.10 Tilgængelighed Ved tilgængelighed forstås forholdet mellem det tidsrum, hvori Systemet rent faktisk er tilgængeligt for ATP s brugere af Systemet samt borgerne, og den planlagte oppetid. Måleperiode Kritisk Forretningstid Faktisk oppetid Nedetid Servicevinduer Bilag 7 Side 8 af 46 8
Figur 1 Nedbrydning af måleperiode i forbindelse med tilgængelig tid Nedetid regnes fra det tidspunkt, hvor et Incident med enten prioritet 1 eller prioritet 2 konstateres eller burde være konstateret (enten via indrapportering eller via modtagelse af en alarm fra driftsovervågningen), indtil Incidentet er afhjulpet og meddelt til ATP. Kritisk Forretningstid ( med bod) Leverandøren skal være opmærksom på, at indenfor Kritisk Forretningstid (jf. punkt 3.2) skal den tid, hvor der findes åbentstående Incidents med enten prioritet 1 eller prioritet 2, medregnes som nedetid. Incidents tidsstempler for Åbnet og Løst (af Leverandør) anvendes til beregning af tillæg til nedetid. Perioder udenfor Kritisk Forretningstid Leverandøren skal være opmærksom på, at såfremt der findes åbentstående Incidents med enten Prioritet 1 eller Prioritet 2 i resterende tid, skal det medregnes i nedetid, men indgår ikke i bodsopgørelse. Følgende forhold medfører ikke, at Systemet er utilgængelig (nedetid), og fragår dermed ikke i opgørelsen af den tilgængelige tid: Driftshindringer, som Leverandøren ikke er ansvarlig for. Fejl, hvor enkelte arbejdspladser eller enkelte mindre væsentlige funktioner midlertidigt ikke kan anvendes, men hvor det i øvrigt er muligt at anvende den normale funktionalitet (prioritet 3 og 4 Incidents, jf. punkt 3.9 ovenfor). Fejl, hvor ATP vælger at udskyde fejlrettelsen. Udnyttelse efter ATP s godkendelse af planlagte servicevinduer, jf. punkt 3.6. Fejl af typen Nærved fejl med prioritet 1 eller 2, jf. punkt 3.9. 3.11 Måling og rapportering af Leverandøren skal måle og rapportere på alle anført i punkt 4 fra og med Overtagelsesdagen. er opdelt i: 1. med bod (direkte bodsberegning). 2. med KPI (indirekte bodsberegning). Bilag 7 Side 9 af 46 9
Leverandøren foretager månedlig bodsberegning i overensstemmelse med bodsbestemmelserne for ene fra og med Overtagelsesdagen. De to bodsberegningsmetoder gennemgås i punkt 5. 3.11.1 Måling af Leverandøren skal måle opfyldelse af ene ved at anvende de måleværktøjer og metoder, som Leverandøren har beskrevet i punkt 6 i dette bilag. ATP har til enhver tid ret til at få efterprøvet målingen af af enten ATP selv eller tredjepart. 3.11.2 Opgørelse af sopfyldelse ved begrænset datagrundlag Ved begrænset datagrundlag på grund af få månedlige målepunkter erstattes det procentbaserede med et maksimalt antal afvigelser, der er tilladt pr. måleperiode. Begrænset datagrundlag udgøres af: 1-20 målepunkter for KPI er med 95 % 1-34 målepunkter på KPI er med 97 % 1-40 målepunkter på KPI er med 97,5 % 1-50 målepunkter på KPI er med 98 % 1-100 målepunkter på KPI er med 99 % I det følgende er, der er omfattet af denne opgørelsesmetode markeret med MAX ANTAL (antal), hvor tallet i parentes indikerer det maksimalt tilladte antal overskridelser af et. Når der angives MAX ANTAL (0= ingen) menes, at der ikke tillades overskridelser for dette. 3.11.3 Manglende måling og/eller rapportering Hvis Leverandøren undlader at måle og/eller rapportere på et eller flere, der på det pågældende tidspunkt er gældende, antages serviceniveauet for det/de pågældende at være på det niveau, der udløser maksimal bod. Bilag 7 Side 10 af 46 1
4 ATP efterspørger sikker og stabil drift af Systemet og ønsker en incitamentsmodel, der motiverer Leverandøren til at levere dette. I dette punkt beskrives de forskellige, som Leverandøren skal måle på og sikre overholdelsen af. Tabellen nedenfor viser en oversigt over samtlige og hvorvidt de er belagt med bod eller KPI med gradueret bod. KPI Reference Tilgængelighed af Systemet. X 4.1.1 Svartider for Systemet. X 4.1.2 for Løbende Drift vedrørende servicedesk og Incident Management Svartid i Leverandørens servicedesk. X 4.2.1.1 Reaktionstid ifm. Incidents. Reaktionstid ifm. Prioritet 1 Incidents X 4.2.1.2 Reaktionstid ifm. Prioritet 2 Incidents X 4.2.1.2 Reaktionstid ifm. Prioritet 3 Incidents X 4.2.1.2 Reaktionstid ifm. Prioritet 4 Incidents X 4.2.1.2 Kommunikationstid ifm. Incidents. Kommunikationstid ifm. Prioritet 1 Incidents. X 4.2.1.3 Kommunikationstid ifm. Prioritet 2 Incidents. X 4.2.1.3 Kommunikationstid ifm. Prioritet 3 Incidents. X 4.2.1.3 Kommunikationstid ifm. Prioritet 4 Incidents. X 4.2.1.3 Bilag 7 Side 11 af 46 1
KPI Reference Løsningstid ifm. Incidents (infrastruktur). *Bemærk at Incidents med Prioritet 1 eller Prioritet 2 tæller med i opgørelse af Tilgængelighed og dermed i direkte bod. Løsningstid ifm. Prioritet 1 Incidents (infrastruktur). X 4.2.1.4 Løsningstid ifm. Prioritet 2 Incidents (infrastruktur). X 4.2.1.4 Løsningstid ifm. Prioritet 3 Incidents (infrastruktur). X 4.2.1.4 Løsningstid ifm. Prioritet 4 Incidents (infrastruktur). X 4.2.1.4 Fyldestgørende redegørelse efter Major Incident. X 4.2.1.5 vedrørende Problem Management Udarbejdelse af Root Cause-analyser X 4.2.2.1 vedrørende Change Management Fyldestgørende Request for Change (RFC). X 4.2.3.1 Changes leveret og implementeret succesfuldt. X 4.2.3.2 Emergency Changes. X 4.2.3.3 Changes gennemført udenom Change Management-processen. X 4.2.3.4 vedrørende Release Management Releases leveret med aftalt scope. X 4.2.4.1 vedrørende it-sikkerhed Succesfuld gennemførelse af back-up og genetablering. X 4.2.5.1 Afprøvning af beredskabsplan. X 4.2.5.2 Fyldestgørende rapportering om brud på IT sikkerhedsmæssige krav. X 4.2.5.3 vedrørende validation and control Afvikling af batchkørsler. Bilag 7 Side 12 af 46 1
KPI Reference Afvikling af batchkørsler kategori A. X 4.2.6.2 Afvikling af batchkørsler kategori B. X 4.2.6.2 Afvikling af batchkørsler kategori C. X 4.2.6.2 Afvikling af batchkørsler kategori D. X 4.2.6.2 vedrørende dokumentation Levering af fyldestgørende dokumentation. X 4.2.7.1 vedrørende rapportering Rettidig rapportering. X 4.2.8.1 vedrørende standardserviceydelser Leveringstid for standardserviceydelser. X 4.2.9.1 vedrørende Desktop Management Frigivelse af MSI pakker. X 4.2.10.1 for Vedligeholdelse og videreudvikling af Systemet Løsningstid ifm. Fejl og mangler (Applikation) *Bemærk at Incidents med Prioritet 1 eller Prioritet 2 tæller med i opgørelse af Tilgængelighed og dermed i direkte bod. Løsningstid ifm. Fejl og mangler (Applikation) prioritet 1, indenfor 8 timer X 4.3.1 Løsningstid ifm. Fejl og mangler (Applikation) prioritet 1, indenfor 16 timer X 4.3.1 Løsningstid ifm. Fejl og mangler (Applikation) prioritet 2, indenfor 24 timer X 4.3.1 Løsningstid ifm. Fejl og mangler (Applikation) prioritet 2, indenfor 32 timer X 4.3.1 Løsningstid ifm. Fejl og mangler (Applikation) prioritet 3, indenfor 2 releases X 4.3.1 Løsningstid ifm. Fejl og mangler (Applikation) prioritet 4, til aftalt tid X 4.3.1 Estimering af tilpasninger vedligehold og support Bilag 7 Side 13 af 46 1
KPI Reference Estimering af tilpasninger vedligehold og support kategori B og C indenfor 5 Arbejdsdage X 4.3.3.1 Estimering af tilpasninger vedligehold og support kategori B og C indenfor 8 Arbejdsdage X 4.3.3.1 Kvalitet af løsning. Tilpasning og vedligehold X 4.3.3.2 vedrørende udviklingsprojekter Reaktionstid bestilling af estimat over vederlag for projektaftale. X 4.3.4.1 Udarbejdelse af projektaftale. X 4.3.4.2 Projektrapportering. X 4.3.4.3 Tabel 3 Oversigt over samtlige 4.1 Generelle 4.1.1 Tilgængelighed af Systemet : Tilgængelighed af Systemet Systemet skal have en tilgængelighed på 98,5 % inden for planlagt oppetid, jævnfør punkt 3.10 (Tilgængelighed), og alle servicevinduer skal placeres uden for dette tidsrum. Tilgængeligheden måles for det samlede System indenfor Kritisk Forretningstid (jf. punkt 3.2) Tilgængelighed måles således: Faktisk oppetid Planlagt oppetid x 100 % Måleperiode / Måletidspunkt En måned Måleperiode: et opgøres i Kritisk Forretningstid jf. punkt 3.2. Der måles hvert 5. minut Alternative perioder aftales i Driftsaftalehåndbogen, men indgår ikke i bodsberegningen. Målemetode og værktøj der anvendes til måling af tilgængelighed for Systemet beskrives af Leverandøren i punkt 6 i dette bilag. Bilag 7 Side 14 af 46 1
: Tilgængelighed af Systemet For hvert påbegyndte tiendedel procentpoint tilgængeligheden ligger under den garanterede tilgængelighed, skal Leverandøren betale en bod svarende til 1 procent af Driftsvederlaget for den pågældende måleperiode. Tabel 4 : Tilgængelighed af Systemet 4.1.2 Svartider for Systemet : Svartider for Systemet Mindst 90 % af transaktionernes svartid er indenfor målværdierne for henholdsvis Teknisk svartid og Samlet svartid som angivet i tabellerne nedenfor i punkt 4.1.3 Teknisk svartid: Omfatter udelukkende den interne procestid i Systemet, dvs. ekskl. den tid, der anvendes af eksterne systemer og integrationer. Også benævnt Intern svartid. Måleperiode / Måletidspunkt Samlet svartid Systemets samlede svartid, dvs. inkluderer også den tid, som andre eksterne systemer anvender samt transporttiden over internet / internt netværk. Også benævnt Brugeroplevet svartid. Aggregerede målinger pr. periode (Dag og måned) fra Leverandørens måleværktøj, specificeres i Driftsaftalehåndbog. En måned. Måleperiode: et opgøres i Kritisk Forretningstid jf. punkt 3.2. Der måles hvert 5. minut. Alternative perioder aftales i Driftsaftalehåndbogen, men indgår ikke i beregning. Bilag 7 Side 15 af 46 1
: Svartider for Systemet Svartidsopfyldelsen opgøres for hver enkelt transaktion, Dog således at samtidige overskridelser af Teknisk svartid maksimum tæller én (1) gang, når nedetid tillægges tilgængelighedsmålet jf. punkt 1 nedenfor: 1. Hvis svartidsforringelsen for Teknisk Svartid (målsætning)" er større end eller lig med 100 % forringelse betragtes Systemet som utilgængeligt og der ifaldes bod for utilgængelighed. For udvalgte transaktioner er "Teknisk svartid (maksimum)" angivet med værdier, der er mindre end 100 % overskridelse, i disse tilfælde er det "Teknisk svartid (maksimum)", der angiver, hvornår systemet betragtes som utilgængeligt og der ifaldes bod for utilgængelighed. 2. Hvis svartid for Teknisk Svartid (målsætning) forringes 10-99,9 %, så ifaldes bod på svartid, og boden udgør: For hvert påbegyndte 10 procentpoint svartiden ligger over målsætningen for den Tekniske svartid skal Leverandøren betale en bod svarende til 1 procent af Driftsvederlaget for den pågældende måleperiode. Tabel 5 : Svartider for Systemet Bilag 7 Side 16 af 46 1
Borger 4.1.3 Krav til svartid per svartidstype Svartidsmålingerne gennemføres på baggrund af en række transaktioner. Transaktionerne er inddelt i tre svartidstype, Nem, Middel og Kompleks, som afspejler transaktionernes kompleksitet og dermed forventningerne til svartiden. For hver svartidstype er der udvalgt transaktioner for henholdsvis en borger og en kunderådgiver. Der skal foretages svartidsmålinger for alle transaktionerne i Tabel 6 nedenfor. Teknisk Teknisk Samlet Samlet svartid svartid svartid svartid TYPE (Kompleksitet) Definition Eksempler (målsætning) (maksimum) (målsætning) (maksimum) sek. sek. sek. * sek. * Nemme Simpelt opslag og visning af Vis oversigt over udbetalt boligstøtte pr. måned/kvartal. 0,5 1,0 1,0 1,5 sagsdata Visning af måneder/kvartaler, år, beløb samt samlede udbetalinger for indeværende år. Nemme Simpelt opslag og visning af Vis oversigt over: stamoplysninger: fx cpr.nr., navn, 0,5 1,0 1,0 1,5 stamdata adresse, civilstand eventuelle hustandsmedlemmer. Middel Enkelt indberetning og Godkend/berig datagrundlag, når en borger udfylder 1,0 1,5 2,0 3,0 godkendelse af data felter og derefter går fra et trin til det næste i selvbetjeningsløsningen (godkender). Bilag 7 Side 17 af 46
Teknisk Teknisk Samlet Samlet svartid svartid svartid svartid TYPE (Kompleksitet) Definition Eksempler (målsætning) (maksimum) (målsætning) (maksimum) sek. sek. sek. * sek. * Middel Simulering af mulighed for Lav en simulering af foreløbig boligstøtte (det vil sige en 1,0 1,5 2,0 3,0 boligstøtte foreløbig beregning af om borger er berettiget til boligstøtte). Middel Validering og godkendelse af data Valider og godkend ansøgning om boligstøtte 1,0 1,5 2,0 3,0 Middel Indberetning af ændring til Indberetning af ændring til en eksisterende sag, fx en 1,0 1,5 2,0 3,0 en eksisterende sag modtager af boligstøtte der via selvbetjeningsløsningen meddeler ønsket om at stoppe udbetalingen af boligstøtte. Komplekse Indberetning og vedhæft- Indberet ændring i indkomst og vedhæft dokumentation 4,0 5,0 6,0 7,0 ning af dokumentation via selvbetjeningsløsningen. Komplekse Tjek for underskrift om Validering af, om der er modtaget underskrifter om 4,0 5,0 6,0 7,0 samtykke og solidarisk solidarisk hæftelse og samtykke fra husstandsmed- hæftelse lemmer. Bilag 7 Side 18 af 46
Kunderådgiver Teknisk Teknisk Samlet Samlet svartid svartid svartid svartid TYPE (Kompleksitet) Definition Eksempler (målsætning) (maksimum) (målsætning) (maksimum) sek. sek. sek. * sek. * Nemme Visning af indbakken. Kunderådgiveren eller lederen åbner indbakken, for at få et overblik og/eller påbegynder sagsbehandling. 0,5 1,0 1,0 1,5 Nemme Opslag og visning af tvær- Kunderådgiveren taster borgerens cpr.nr. Ind i systemet 0,5 1,0 1,0 1,5 gående overblik. og det tværgående overblik bliver vist. Middel Åbning af en konkret opga- Kunderådgiveren tager en arbejdspakke i indbakken og 1,0 2,0 2,0 3,0 ve i indbakken åbner opgaven. Opgaven låses og et skærmbillede med relevante oplysninger for behandlingen af opgaven vises. Middel Åbning af konkret I forbindelse med telefonbetjeningen, har kunderådgive- 1,0 2,0 2,0 3,0 brev/digital besked ren behov for at åbne et brev/digital besked (både indgående/udgående). Middel Udfyldelse af Brevskabelon Kunderådgiveren har valgt en brevskabelon og udfylder oplysninger. Data hentes og vises undervejs og til sidst i en samlet version. 1,0 2,0 2,0 3,0 Bilag 7 Side 19 af 46
Teknisk Teknisk Samlet Samlet svartid svartid svartid svartid TYPE (Kompleksitet) Definition Eksempler (målsætning) (maksimum) (målsætning) (maksimum) sek. sek. sek. * sek. * Middel Udfyldelse af Journalnotat Kunderådgiveren har valgt at skrive et journalnotat og udfylder oplysningerne. Data hentes og vises undervejs og til sidst i en samlet version. Middel Åbning gældsoversigt Kunderådgiveren får vist en gældsoversigt og kan så vælge at se detaljer for de enkelte gældsposter. Komplekse Omberegning af ydelse Kunderådgiver foretager en omberegning på baggrund af ændrede oplysninger fx formue, som borger har indberettet. 1,0 2,0 2,0 3,0 1,0 2,0 2,0 3,0 2,0 3,0 5,0 6,0 Komplekse Oprettelse og journalisering Kunderådgiveren afslutter en henvendelse med at lave 2,0 3,0 5,0 6,0 af manuelt brev et manuelt brev. Skabelonen vælges, udfyldes og gemmes. Brevet journaliseres og vil derefter fremgå af det tværgående overblik. Komplekse Afslutning af sag. Kunderådgiveren har taget en arbejdspakke i indbakken og færdigbehandlet opgaven. Opgaven afsluttes og ændrer status til afsluttet. Ændringen er gennemført og fremgår som afsluttet af sagsoversigten og optræder 2,0 3,0 5,0 6,0 Bilag 7 Side 20 af 46
Teknisk Teknisk Samlet Samlet svartid svartid svartid svartid TYPE (Kompleksitet) Definition Eksempler (målsætning) (maksimum) (målsætning) (maksimum) sek. sek. sek. * sek. * ikke længere i indbakken. * Samlet svartid (målsætning) og Samlet svartid (maksimum) fastlægges og godkendes ved afslutning af samlet systemintegrationstest evt. med tillæg for aftalte svartidsmål fra eksterne integrationsaftaler Tabel 6 Krav til svartid per svartidstype Bilag 7 Side 21 af 46
4.2 for Løbende Drift I det følgende beskrives de overordnede, der er fælles for Ydelserne. I punkt 4.3 beskrives de, som specifikt vedrører vedligeholdelse og videreudvikling (Applikation Management). I de efterfølgende refereres der til Incident-kategorierne beskrevet i 3.9. 4.2.1 vedrørende servicedesk og Incident Management 4.2.1.1 Svartid i Leverandørens servicedesk : Svartid i Leverandørens servicedesk et er, at 95 % eller MAX ANTAL (1) af alle henvendelser skal besvares inden svarfristen. Leverandørens servicedesk skal være tilgængelig og kunne besvare henvendelser fra ATP. Leverandørens servicedesks åbningstid er alle Arbejdsdage mellem klokken 8.00 til 16.00. Telefoniske henvendelser skal besvares personligt inden for maksimalt 90 sekunder. Henvendelser pr. e-mail skal besvares inden for maksimalt 60 minutter. Ved besvarelse forstås, at der enten er opnået telefonisk kontakt til en medarbejder i Leverandørens servicedesk, eller at der er modtaget en kvittering for henvendelser via e-mail, således at henvendelser er registreret hos Leverandøren. Tilgængelighed af servicedesken måles som den procentdel af det samlede antal henvendelser, der besvares inden den maksimale besvarelsestid. Måleperiode / Måletidspunkt En måned. KPI I den månedlige statusrapportering opgøres antal henvendelser med identifikation af henvendelsen, typen af henvendelsen, modtagelsestidspunkt og besvarelsestidspunkt. sopfyldelsen udregnes på baggrund af ovenstående data. Tabel 7 : Svartid af Leverandørens servicedesk Bilag 7 Side 22 af 46 2
4.2.1.2 Reaktionstid i forbindelse med Incidents : Reaktionstid i forbindelse med Incidents Sagsbehandling af 95 % eller MAX ANTAL (1) af Prioritet 1, 2, 3 og 4 Incidents skal igangsættes inden for tidsfristen for reaktionstid for den enkelte kategori. Reaktionstid forstås som det tidsrum, der forløber, fra det tidligste tidspunkt hvor enten Leverandøren konstaterer eller burde have konstateret en Incident eller en Incident konstateres af ATP, frem til det tidspunkt, hvor sagsbehandlingen igangsættes, det vil sige det tidspunkt, hvor den pågældende Incident er allokeret til løsning hos en medarbejder. Prioritet 1 Prioritet 2 Prioritet 3 Prioritet 4 Måleperiode / Måletidspunkt 15 minutter 1 time 8 timer 16 timer Tidsrum Døgnet Servicedeskendeskendeskens Service- Service- rundt alle årets Dage åbningstid åbningstid åbningstid Reaktionstid beregnes som den procentdel af Prioritet 1, 2, 3, og 4 Incidents, der overholder fristen for igangsættelse. et tæller som fire (4) individuelle KPI er i KPI modellen. En måned. KPI I den månedlige statusrapportering opgøres antal henvendelser pr. prioritet med identifikation af henvendelsen, modtagelsestidspunkt, besvarelsestidspunkt og reaktionstidspunkt. sopfyldelsen udregnes på baggrund af ovenstående data. Tabel 8 : Reaktionstid i forbindelse med Incidents. Bilag 7 Side 23 af 46 2
4.2.1.3 Kommunikationstid i forbindelse med Incidents : Kommunikationstid i forbindelse med Incidents Kommunikationstid forstås som det tidsrum, der forløber, fra Leverandøren konstaterer en Incident eller burde have konstateret en Incident, frem til det tidspunkt, hvor Leverandøren giver første tilbagemelding og efterfølgende tilbagemeldinger om sagens status til ATP. Tilbagemeldinger for prioritet 1 og 2 skal ske ved hjælp af telefonopkald til servicedesken hos ATP og e- mails til udvalgte interessenter eller som aftalt i Driftsaftalehåndbogen. Såfremt at Fejlen konstateres udenfor ATP s servicedesks åbningstid, skal ATP kontaktes via eskalationslisten, som fremgår af Driftsaftalehåndbogen. Kommunikationsforpligtigelsen ophører, når sagen er løst. Prioritet 1 Prioritet 2 Prioritet 3 Prioritet 4 Kommunikationstid, første tilbagemelding Kommunikationstid, efterfølgende tilbagemelding(er) 15 minutter 1 time Efter aftale Efter aftale Hver time Efter aftale Efter aftale Efter aftale Måleperiode / Måletidspunkt : Kommunikationstid for 95 % eller MAX ANTAL (1) af prioritet 1, 2, 3 og 4 Incidents skal være overholdt inden for tidsfristen for den enkelte kategori. Kommunikationstid måles som den procentdel af Prioritet 1, 2, 3 og 4 Incidents, der overholder fristen for tilbagemelding. et tæller som fire (4) individuelle KPI er i KPI modellen. En måned. KPI I den månedlige statusrapportering opgøres antal henvendelser pr. kategori med identifikation af henvendelsen, modtagelsestidspunkt, besvarelsestidspunkt, reaktionstidspunkt, løsningstidspunkt og kommunikationstidspunkt(er). sopfyldelsen udregnes på baggrund af ovenstående data. Tabel 9 : Kommunikationstid i forbindelse med Incidents Bilag 7 Side 24 af 46 2
4.2.1.4 Løsningstid i forbindelse med Incidents (infrastruktur) Bemærk for Løsningstid i forbindelse med Fejl og Mangler (applikation) er beskrevet i punkt 4.3. : Løsningstid ifm. Incidents (infrastruktur) Løsningstid forstås som det tidsrum, der forløber, fra Leverandøren konstaterer en Incident eller burde have konstateret en Incident, frem til det tidspunkt, hvor Fejlen er løst. Heri medregnes også den tid, som bruges på afhjælpning af Incidents vedrørende Leverandørens tredjeparts standardsoftware og hardware, som indgår i Leverancen. Prioritet 1 Prioritet 2 Prioritet 3 Prioritet 4 2 timer 4 timer 10 Arbejdsdage Tidsrum Døgnet Servicedeskendeskens Service- rundt alle årets Dage åbningstid åbningstid Efter aftale Efter aftale Måleperiode / Måletidspunkt : Løsning af 95 % eller MAX ANTAL (1) af Prioritet 1, 2, 3 og 4 Incidents skal være gennemført inden for tidsfristen for den enkelte prioritet. Løsningstid beregnes som den procentdel af Prioritet 1, 2, 3 og 4 Incidents, der overholder fristen for løsning. et tæller som fire (4) individuelle KPI er i KPI modellen. En måned. KPI Bemærk at åbentstående Incidents med Prioritet 1 eller Prioritet 2 tæller med i opgørelsen af tilgængelighed I den månedlige statusrapportering opgøres antal henvendelser pr. kategori med identifikation af henvendelsen, modtagelsestidspunkt, besvarelsestidspunkt, reaktionstidspunkt og løsningstidspunkt. sopfyldelsen udregnes på baggrund af ovenstående data. Tabel 10 : Løsningstid i forbindelse med Incidents (infrastruktur) 4.2.1.5 Situation Management Situation Management igangsættes i forbindelse med Major Incidents (prioritet 1). Hvor Leverandøren har ansvar for løsning / omgåelse, er det Leverandørens ansvar at håndtere fejlen i overensstemmelse med Incident Management-processen. Bilag 7 Side 25 af 46 2
: Fyldestgørende redegørelse efter Major Incident Måleperiode / Måletidspunkt Leverandøren skal for hver Major Incident udarbejde en redegørelse og sende til den ansvarlige Situation Manager i ATP. Redegørelsen skal modtages senest to (2) Arbejdsdage efter Major Incident er løst. : 95 % eller MAX ANTAL (1) opfyldt pr. periode et måles som den procentdel af fyldestgørende redegørelser efter Major Incident i forhold til totalt antal Major Incidents. En måned. KPI I den månedlige statusrapportering opgøres antal af Major Incidents inkl. løsningstidspunkt samt modtagelsestidspunkt i ATP for den efterfølgende redegørelse. Andel rettigdige redegørelsen beregnes. Tabel 11 Fyldestgørende redegørelse efter Major Incident 4.2.2 vedrørende Problem Management 4.2.2.1 Udarbejdelse af Root Cause-analyser : Udarbejdelse af Root Cause-analyser Leverandøren skal udarbejde en Root Cause analyse for alle Major incidents (Prioritet 1) og alle Problem Management-sager. Root Cause analyse skal være tilsendt ATP senest ti (10) Arbejdsdage efter problemsag er oprettet eller efter aftale, dog senest inden tyve (20) Arbejdsdage. et er, at Leverandøren skal angive Root Cause rettidigt for 95 % eller MAX ANTAL (1) af Incidents, der er eskaleret til Problems. et måles som den procentdel af rettidige Root Cause analyser i forhold til totalt antal Problems. Måleperiode / Måletidspunkt En måned. KPI. Viser det sig at Root Cause skyldes forhold udenfor Leverandørens ansvarsområde indgår dette ikke i et. I den månedlige statusrapportering opgøres antal Problems inkl. åbningsog løsningstid samt tidspunkt for Root Cause analyse. Tabel 12 : Udarbejdelse af Root Cause analyser Bilag 7 Side 26 af 46 2
4.2.3 vedrørende Change Management 4.2.3.1 Fyldestgørende Request for Change (RFC) : Fyldestgørende Request for Change Leverandøren skal sikre at minimum 95 % eller MAX ANTAL (1) af dennes RFC er fyldestgørende, hvilket betyder: RFC indeholder alle obligatoriske informationer, jævnfør kravene til RFC i bilag 3A.1 (Kravliste). RFC indeholder evt. softwarepakker eller lignende, som er omfattet af RFC. At RFC fremsendes til ATP minimum tyve (20) Arbejdsdage før aftalt implementering. Antallet af ikke-fyldestgørende RFC er opgøres og sammenholdes med antallet af fyldestgørende RFC er. Måleperiode / Måletidspunkt En måned. KPI. Tabel 13 : Fyldestgørende Request for Change. 4.2.3.2 Changes leveret og implementeret succesfuldt : Changes leveret og implementeret succesfuldt Leverandøren skal sikre at minimum 97,5 % eller MAX ANTAL (1)* af alle Changes bliver succesfuldt implementeret, hvilket betyder følgende: Change en implementeres på det aftalte tidspunkt og inden for det aftalte tidsrum. Change en indeholder al aftalt funktionalitet. Change en er fyldestgørende dokumenteret og eventuelle opdateringer til Driftshåndbogen er indarbejdet og godkendt. Implementeringen af Change en udløser ingen prioritet 1- eller 2- Incidents, jævnfør punkt 3.9. *I det første år efter iværksættelse er målet 95 % eller MAX ANTAL (1) og i den resterende del af kontraktperioden er målet 97,5 % eller MAX ANTAL (1). Antallet af Changes implementeret ikke-succesfuldt opgøres og sammenholdes med antallet af Changes implementeret succesfuldt. Changes aflyst af Kunden medtages ikke i beregningen. Måleperiode / Måletidspunkt En måned. Bilag 7 Side 27 af 46 2
: Changes leveret og implementeret succesfuldt For hvert påbegyndte hele procentpoint* resultatet ligger under et skal Leverandøren betale en bod svarende til 1 % af Driftsvederlaget, jf. bilag 5 (Priser og betalingsplan), for den pågældende måleperiode. *ved små sagsmængder (jf. punkt 3.11.2) udløser hver efterfølgende afvigelse pr. måleperiode en bod svarende til 1 % af Driftsvederlaget for den pågældende måleperiode (heraf følger ved 2 afvigelser udløses 2 % osv.). Tabel 14 : Changes leveret og implementeret succesfuldt. 4.2.3.3 Emergency Changes : Emergency Changes. Måleperiode / Måletidspunkt ATP har 3 typer af Changes: Normal, Standard og Emergency. Emergency Change er undtagelsen, og derfor må antallet af Emergency Change højst udgøre 3 % af det samlede antal Changes for Systemet. : 97 % eller MAX ANTAL (1) opfyldt pr. periode. Emergency Changes i forhold til totalt antal Changes for Systemet. Månedligt. KPI. Månedsrapport. Månedsrapport. Tabel 15 : Emergency Changes. 4.2.3.4 Changes gennemført udenom Change Management-processen : Changes gennemført udenom Change Management-processen. Måleperiode / Måletidspunkt Changes til Systemet uden forudgående oprettelse af Change Requests må ikke forekomme. Hvis det konstateres, at der er lavet ændringer i Systemet uden forudgående oprettelse af Change Request, skal Leverandøren uden unødig forsinkelse fremsende dokumentation for Changen. : 100 % eller MAX ANTAL (0= Ingen) opfyldt pr. periode. Antal Changes udenom Change Management-processen i forhold til totalt antal Changes for Systemet. Månedligt. KPI. Bilag 7 Side 28 af 46 2
: Changes gennemført udenom Change Management-processen. Månedsrapport. Månedsrapport. Tabel 16 : Changes gennemført udenom Change Mangement-processen. 4.2.4 vedrørende Release Management 4.2.4.1 Releases leveret med aftalt scope : Releases leveret med aftalt scope Leverandøren skal sikre, at alle Releases indeholder alle de Changes, det er aftalt, at skulle være omfattet af pågældende Release. Antal indmeldte Changes i forhold til iværksat mængde Changes. : 95 % eller MAX ANTAL (1) opfyldt pr. periode. Verificering af at faktisk indhold af Release svarer til aftalt indhold. Antal indmeldte Changes i forhold til iværksat mængde Changes. Changes aflyst af Kunden medtages ikke i beregningen. Måleperiode / Måletidspunkt En måned. KPI. Tabel 17 : Releases med aftalt scope. 4.2.5 vedrørende it-sikkerhed 4.2.5.1 Succesfuld gennemførelse af backup og genetablering : Succesfuld gennemførelse af backup og genetablering Leverandøren skal sikre, at der tages backup af Systemet. Eventuelle undtagelser fra backup dokumenteres i Driftsaftalehåndbogen. Der skal hver Dag foretages 100 % eller MAX ANTAL (0 = Ingen manglende) backup, som skal gennemføres hele døgnet alle ugens dage af Systemet jf. backupstrategien, som beskrevet af Leverandøren i bilag 3B (Løsningsbeskrivelse). et er, at 100 %, det vil sige alle backupper, udføres jf. punkt 0, og at Leverandøren skal kunne afslutte succesfuld genetablering af alle backupper senest 24 timer efter ATP s skriftlige påkrav, medmindre andet aftales i Driftsaftalehåndbogen. Bilag 7 Side 29 af 46 2
: Succesfuld gennemførelse af backup og genetablering Korrekt backup måles som den procentdel af de aftalte backupper, der er gennemført til aftalt tid og i det aftalte tidsrum. Såfremt en backup er startet før det aftalte tidsrum og/eller afsluttet efter det aftalte tidsrum, vil backup ikke være gennemført korrekt i forhold dette. Ved korrekt backup forstås, at backupafviklingen er sket uden, at der opstod fejl, og at den tagne backup indeholder de forventede data, som verificeres ved afprøvning af genetablering. Leverandøren skal pr. Dag dokumentere antal succesfyldte gennemførte backupper og totalt antal backupper. Genetablering af backupper måles ved, at Leverandøren mindst en gang årligt og altid efter større Ændringer skal gennemføre afprøvning af genetablering af seneste backupper til at genskabe et fuldt operationelt miljø. Succesfuld genetablering er den procentdel af Systemet, der kan reetableres indenfor 24 timer, eller som aftalt i Driftsaftalehåndbogen, uden nogen form for tab af data (manglende genetablerede backupper). Såfremt afprøvning af genetablering ikke kan gennemføres succesfuldt, skal backup for relevante periode, dvs. perioden fra den sidste foretagne korrekte backup, gennemføres inden tre (3) Arbejdsdage, og afprøvning af genetablering skal gentages inden fem (5) Arbejdsdage. Måleperiode / Måletidspunkt Hver måned opgøres udførte backupper. To (2) gange årligt ved udførelse af genetablering. KPI. I den månedlige statusrapportering opgøres antal aftalte backupper og antal udførte backupper. Der udarbejdes to gange årligt, for eksempel i forbindelse med den månedlige statusrapportering, en testrapport fra den gennemførte afprøvning af genetablering indeholdende antal applikationer i forsøgte genetableringer og antal applikationer, data, Programmel mv. i succesfuldt gennemførte genetableringer. Ved den månedlige statusrapportering og i forbindelse med test af genetablering, senest ti (10) Dage efter afprøvningens afslutning. Tabel 18 : Succesfuld gennemførelse af backup og genetablering. Bilag 7 Side 30 af 46 3
4.2.5.2 Afprøvning af beredskabsplan : Afprøvning af beredskabsplan Måleperiode / Måletidspunkt Leverandøren skal, i tilfælde af Katastrofe, kunne reetablere Systemet ud fra Beredskabsplanen og alle underliggende elementer, for eksempel Programmel, data, kommunikationsinfrastruktur, maskinel m.v., der skal til for at drive Systemets væsentligste bestanddele jf. punkt 3.4 i overensstemmelse med ene, inden for 24 timer. : 100 % eller MAX ANTAL (0 = ingen) opfyldt pr, periode. Leverandøren skal hvert år afprøve reetablering én (1) gang. Parterne skal under udarbejdelse af Driftsaftalehåndbogen sammen fastlægge den endelige dato og beredskabsplan herfor. Systemet er operationelt, når applikationen og underliggende elementer kan afvikles i overensstemmelse med ene i dette bilag. En gang årligt. KPI. Testrapport fra gennemført reetableringsafprøvning, som er godkendt af ATP. Årligt ved den førstkommende månedlige statusrapportering. Tabel 19 : Afprøvning af Beredskabsplan. 4.2.5.3 Fyldestgørende rapportering om brud på it-sikkerhedsmæssige krav : Fyldestgørende rapportering om brud på it-sikkerhedsmæssige krav Leverandøren skal straks og uden ophold underrette ATP i tilfælde af brud på de it-sikkerhedsmæssige krav og procedurer i Kontrakten, herunder bilag 13 (Sikkerhed), samt en plan for udbedringer. Revisionsrapporter og erklæringer må ikke indeholde anmærkninger, som betyder, at der er sket væsentlige brud på de it-sikkerhedsmæssige krav i Kontrakten, herunder bilag 13 (Sikkerhed). et er opfyldt, hvis alle revisionserklæringer er afleveret rettidigt og ikke indeholder anmærkninger om væsentlige brud på de itsikkerhedsmæssige krav i Kontrakten, og der ikke er konstateret væsentlige mangler i forhold til de it-sikkerhedsmæssige krav i øvrigt. : 100 % eller MAX ANTAL (0 = ingen) opfyldt pr. periode. Bilag 7 Side 31 af 46 3
: Fyldestgørende rapportering om brud på it-sikkerhedsmæssige krav Leverandøren udarbejder og vedligeholder en liste over datoer for fremsendt rapportering om brud på it-sikkerhedsmæssige krav og evt. anmærkninger heri. Det konstateres ved Leverandørens aflevering af revisionsrapporter og erklæringer til ATP, om dette er sket rettidigt. ATP vurderer, om eventuelle anmærkninger betyder væsentlige brud, som dette almindeligvis forstås, på de it-sikkerhedsmæssige krav, der skal afhjælpes. Ligeledes konstateres det via øvrige verifikationsprocedurer, om der er konstateret væsentlige mangler (som dette begreb almindeligvis forstås i forhold til best practices for IT sikkerhed) i forhold til de it-sikkerhedsmæssige krav. I så fald meddeles dette skriftligt af ATP til Leverandøren. Måleperiode / Måletidspunkt Ved aflevering. KPI. Ved aflevering. Ved aflevering. Tabel 20 : Fyldestgørende rapportering om brud på it-sikkerhedsmæssige krav. 4.2.6 vedrørende validation and control 4.2.6.1 Batchkategorier I ene for Afvikling af batch refereres til fire batchkategorier (A, B, C,D). Kategorierne er defineret i nedenstående tabel. Batchkørsler ved udarbejdelsen af Driftsaftalehåndbogen, jf. bilag 4 (Dokumentation), i samarbejde med ATP, inddeles i de fire batchkategorier. Batchkategori A Kritiske kørsler, der kræver særlig awareness Kriterier for udvælgelse Direkte kundepåvirkning ved nedbrud eller for sen levering. Udbetaling: Omfanget af kundepåvirkning i antal og beløb skal ligeledes udgøre mindst 10.000 kunder og/eller 50 mio. kr., og kunden er opmærksom på, hvornår der kan disponeres over udbetalingen. Opkrævning: Omfanget af kundepåvirkning i beløb skal udgøre mindst 150 mio. kr. Bilag 7 Side 32 af 46 3
Batchkategori B Forretningskritiske kørsler med daglig rapportering C Standard Kriterier for udvælgelse Direkte kundepåvirkning ved nedbrud eller for sen levering af overførsel Udbetaling: Alle udbetalinger. Opkrævning: Hovedopkrævninger er Kategori A. I kat. B kan medtages opkrævninger for eksterne kunder. Breve med særlig konsekvens (f.eks. breve med oplysningspligt). Alle kalenderlagte kørsler og forud aftalte leverancer fra eksterne parter (der ikke er med i kategori A og B). D Ikke tidsbundne kørsler ikke-forretningskritisk opgave (udtræk af statistik, fejllister, m.v.). Tabel 21 Batchkategorier. 4.2.6.2 for afvikling af batch for afvikling af batch Der er følgende : Batchkategori A: 100 % eller MAX ANTAL (0= ingen) af Kategori A- kørslerne er korrekt afstemt og afviklet til aftalte deadline. Batchkategori B: Mindst 99 % eller MAX ANTAL (1) af Kategori B- kørslerne er korrekt afstemt og gennemført til aftalte deadline. Batchkategori C: Mindst 98 % eller MAX ANTAL (1) af ordningens Kategori C-kørsler (standard) er gennemført til aftalte deadline. Måleperiode / Måletidspunkt Batchkategori D: Mindst 98 % eller MAX ANTAL (1) af ordningens kategori D-kørsler er gennemført til aftalte deadline. Batchkategori A: For hvert kritisk flow. Batchkategori B: aftales, og forankres i Driftsaftalehåndbogen. Batchkategori C: aftales, og forankres i Driftsaftalehåndbogen. Batchkategori D: aftales, og forankres i Driftsaftalehåndbogen. et tæller som fire (4) individuelle KPI er i KPI modellen. En måned. KPI. Bilag 7 Side 33 af 46 3
for afvikling af batch Der skal rapporteres på: Batchkategori A: Leverandør rapporterer hver time til ATP og daglig rapport med seneste døgns afvikling på medarbejderportal opdateres kl. 08.00 samt løbende over dagen. Batchkategori B: Leverandør udarbejder en daglig rapport med seneste døgns afvikling på Kundens medarbejderportal (SharePoint). Rapporten opdateres kl. 08.00 og løbende over dagen. Herudover redegørelse om nedbrud via IT Servicemanagement systemet. Batchkategori C: Rapportering om nedbrud via Incident system. Batchkategori D: Rapportering om nedbrud via Incident system. I månedsrapporten medtages samlet status for måneden pr. kategori samt kritiske afvigelser. Tabel 22 : Afvikling af batch. 4.2.7 vedrørende Dokumentation 4.2.7.1 Levering af fyldestgørende Dokumentation : Levering af fyldestgørende Dokumentation et er opfyldt, hvis 100 % eller MAX ANTAL (0 = ingen) af Dokumentationen er opfyldt rettidigt og korrekt afspejler Driftsmiljøet. Leverandøren skal sikre, at Driftsmiljøet er behørigt dokumenteret. Al Dokumentation af Driftsmiljøet, herunder beredskabsplan, skal opdateres i forbindelse med implementering af Ændringer i Driftsmiljøet. En Ændring kan således ikke godkendes, hvis der ikke foreligger opdateret Dokumentation og en tilhørende plan for, hvordan denne Dokumentation frigives. Dokumentation af Driftsmiljøet måles som den procentdel af Ændringer, der er godkendt og dokumenteret rettidigt. Leverandøren udarbejder en liste over månedens Ændringer og dato for udført opdatering af Dokumentationen. ATP kan selv foretage stikprøver. Måleperiode / Måletidspunkt En måned. KPI I den månedlige statusrapportering opgøres rettidig dokumentationstidspunkt og faktisk dokumentationstidspunkt pr. Ændring, samt om Dokumentationen er godkendt af ATP, som værende retvisende. På baggrund af ovenstående registreringer opgøres et. Bilag 7 Side 34 af 46 3
: Levering af fyldestgørende Dokumentation I den månedlige statusrapportering. Tabel 23 : Levering af fyldestgørende dokumentation. 4.2.8 vedrørende rapportering 4.2.8.1 Rettidig rapportering : Rettidig rapportering Leverandøren skal levere rettidig og korrekt rapportering jf. kravene i bilag 8 (Samarbejdsorganisation og rapportering) og eventuelt Driftsaftalehåndbogen. et er opfyldt, hvis al aftalt rapportering afleveres rettidigt, dvs. i overensstemmelse med de aftalte frister, og er retvisende, dvs. at ATP ikke har væsentlige bemærkninger til rapporteringen og den afspejler de faktiske forhold. Ved væsentlige bemærkninger forstås, at rapporteringen ikke kan godkendes, og at denne skal fremsende i revideret udgave til godkendelse. : 95 % eller MAX ANTAL (1) opfyldt pr. periode. Leverandøren udarbejder og vedligeholder en liste over dato for fremsendt rapporteringer og evt. anmærkninger heri. Det konstateres ved Leverandørens aflevering af rapporteringer til ATP, om dette er sket rettidigt. ATP vurderer, om rapporteringen er retvisende og afspejler de faktiske forhold, herunder om der er væsentlige forhold, som gør at rapporteringen ikke kan godkendes. I tvivlstilfælde drøftes dette med Leverandøren. Såfremt ATP i øvrigt konstaterer, at rapportering ikke er retvisende meddeles dette skriftligt af ATP til Leverandøren. Måleperiode / Måletidspunkt Ved aflevering og ATP løbende anvendelse af rapportering. KPI. Tabel 24 : Rettidig rapportering Bilag 7 Side 35 af 46 3
4.2.9 vedrørende standardserviceydelser 4.2.9.1 Leveringstid for standardserviceydelser : Leveringstid for standardserviceydelser Måleperiode / Måletidspunkt Dette måler på antallet af standardserviceydelser (jf. bilag 5 og bilag 5A), der leveres indenfor den aftalte leveringstid. et er, at maksimalt tre (3) standardserviceydelser må leveres ikke-rettidigt pr. periode. Antallet af standardserviceydelser, der ikke er leveret rettidigt opgøres. En måned. KPI. Tabel 25 : Leveringstid for standardserviceydelser 4.2.10 vedrørende Desktop Management I forbindelse med iværksættelse af Ændringer er der knyttet følgende til Desktop Management. 4.2.10.1 Frigivelse af MSI pakker Frigivelse af MSI pakker Måleperiode / Måletidspunkt Når PC-klient software skal opdateres, skal Leverandøren frigive MSIsoftware til afprøvning, jf. bilag 6 (Afprøvninger), senest tyve (20) Dage før aftalt idriftsættelse. : 95 % eller MAX ANTAL (1) opfyldt pr. periode. et udgår, hvis der ikke anvendes MSI pakker. Leverandøren skal angive frigivelsesdato på alle MSI pakker, og denne dato skal sammenholdes med releasedato for software rettelse. Løbende over en måned. KPI. Tabel 26 : Frigivelse af MSI pakker. Bilag 7 Side 36 af 46 3