Bilag 6 - Servicemål_ver.1.17 · Web viewHvis system A stadig er utilgængeligt betales fortsat 6.000 kr. per time. Eksempel 2: Systemerne A (kategori 1) og C (kategori 3) bliver

GLR/CHR drift, vedligehold og videreudviklingBilag 6 – Servicemål

August 2016

Journal nr.: 2016-43-123-00089

Fødevarestyrelsen • Stationsparken 31-33 • DK-2600 GlostrupTel +45 72 27 69 00 • Fax +45 72 27 65 01 • CVR 62534516 • EAN 5798000986008 • www.fvst.dk/kontakt • www.fvst.dk

INDHOLD 1. INDLEDNING ........................................................................................................... 3

1.1. SAMMENHÆNG TIL ØVRIGE BILAG...............................................................................3

2. GENERELT OM MÅLING OG RAPPORTERING AF SERVICEMÅL ............................ 4

3. DRIFT AF SYSTEMET ............................................................................................... 5

3.1. SERVICEMÅL: TILGÆNGELIGHED.................................................................................53.2. SERVICEMÅL: KONTINUERLIG DRIFTSTID.....................................................................63.3. BOD VED MANGLENDE OPFYLDELSE AF SERVICEMÅL: TILGÆNGELIGHED..........................83.4. HÅNDTERING AF BODSBETALING FOR TILGÆNGELIGHED................................................8

4. SUPPORT ................................................................................................................. 9

4.1. SERVICEMÅL: REAKTIONSTIDER VED FEJL I SYSTEMET..................................................9

5. VEDLIGEHOLD OG VIDEREUDVIKLING ................................................................ 11

5.1. SERVICEMÅL: REAKTIONSTIDER VED BEHOV FOR VEDLIGEHOLDELSE OG UDVIKLING.......115.2. SERVICEMÅL: OVERHOLDELSE AF ESTIMATER FOR VEDLIGEHOLDELSE OG UDVIKLING......11

6. SERVICEVINDUER OG BATCHVINDUER .............................................................. 13

6.1. SERVICEVINDUER....................................................................................................136.2. BATCHVINDUER......................................................................................................13

7. SERVICEMÅL – REETABLERING AF SYSTEMET ................................................... 14

8. DOKUMENTATION ................................................................................................ 15

8.1. SERVICEMÅL: FREMVISNING AF DOKUMENTATION......................................................158.2. BOD VED MANGLENDE OPFYLDELSE AF SERVICEMÅL: DOKUMENTATION.........................15

9. SVARTIDER ............................................................................................................ 16

9.1. AFVIKLINGSTIDER FOR BATCHKØRSLER......................................................................179.2. BOD VED IKKE KORREKT GENNEMFØRT BATCHKØRSEL................................................17


2 / 1 9

1. IndledningDette bilag angiver Servicemål, som Leverandøren skal efterleve i hele kontraktperioden.

Tilbudsgiver skal udfylde de felter, der er markeret med GULT.

1.1. Sammenhæng til øvrige bilagDette bilag har sammenhæng til nedenstående bilag:

● Bilag 3 – Ydelsesbeskrivelse● Bilag 4 - Kravspecifikation● Bilag 8 - Prøver


3 / 1 9

2. Generelt om måling og rapportering af ServicemålLeverandøren er forpligtet til at måle de i dette bilag angivne Servicemål.

Leverandøren er forpligtet til i månedsrapporten at rapportere om opfyldelsen af Servicemål, der er anført i dette bilag. Rapporteringen skal omfatte relevant dokumentation, således at Kunden kan verificere de foretagne beregninger.


4 / 1 9

3. Drift af Systemet3.1. Servicemål: TilgængelighedServicemålet tilgængelighed måler på Leverandørens evne til at sikre driftsstabiliteten af GLR/CHR Systemkomplekset.

Systemet skal som udgangspunkt være til rådighed for brugerne døgnet rundt 7 dage om ugen, både via brugergrænsefladen og via Systemets tekniske grænseflader.

Ved Leverandørens overtagelse lever Systemet op til tilgængelighedskravene i tabel 3.1.

Tilgængeligheden måles på brugergrænseflader og integrationer, herunder webservices. Der skelnes ikke imellem utilgængelighed forårsaget af applikationer og databasen.

Driftstid Minimum månedlig tilgængelighed

Tilbudsgiver skal angive

tilbudt månedlig tilgængelighed

Primær driftstid 8.00 – 16.30 på hverdage

98 %

Sekundær driftstid Resterende tid 95 %Tabel 3.1. Tilgængelighed.

For den anførte tilgængelighed i tabel 3.1 gælder:

Tilgængelig tid defineres som den tid, hvor Systemet er normalt tilgængeligt (Systemet har ingen fejl af typen kritisk eller høj, jf. tabel 4.2)

Utilgængelighed starter når Kunden eller Leverandøren konstaterer at Systemet ikke er normalt tilgængeligt

Utilgængelighed registreres af Kunden, en af Kundens samarbejdspartnere, eller af Leverandøren. Registrering kan ske via alarmer eller via ITSM

Utilgængeligheden standser, når Kunden eller Leverandøren konstaterer, at Systemet igen er normalt tilgængeligt

Tilgængelighed opgøres ved afslutning af hver kalendermåned


5 / 1 9

Tilgængeligheden beregnes for henholdsvis primær driftstid og sekundær driftstid jf. tabel 3.1 Leverandørens tilgængelighedsprocent (T %) måles på følgende måde pr. måned.

Aftalt driftstid - utilgængelighed i aftalt driftstidT %= Aftalt driftstid X 100

Aftalt driftstid og målt tid for utilgængelighed opgøres i minutter.

Manglende tilgængelighed indgår ikke i beregningen af nedetid, såfremt Leverandøren kan dokumentere, at det skyldes:

a) forhold, som Kunden er ansvarlig for (herunder f.eks. Kundens ønske om at udskyde fejlrettelse), eller

b) driftshindringer forårsaget af skriftligt aftalt utilgængelighed ved forebyggende vedligeholdelse eller backup herunder i ekstraordinære servicevinduer, hvor nedetid er skriftligt aftalt med Kunden på forhånd. Faste servicevinduer anses som skriftligt aftalte.

Eksempel: I en kalendermåned har der været en periode på 2 timer i perioden 8:00 – 16:30 hvor systemet har haft en fejl af typen kritisk eller høj. Der er 22 hverdage i måneden (11.220 minutter).

(11.220 minutter – 120 minutter) x 100 = 98,93 %11.220 minutter

3.2. Servicemål: Kontinuerlig driftstidUd over de tilgængelighedskrav, der er opstillet i afsnit 2.1, er der i tillæg hertil opstillet særlige krav til varigheden af eventuelle nedbrud – fordelt på applikationer og integrationer.

I tabel 3.2 og 3.3 er GLR/CHR applikationer og integrationer kategoriseret med 1, 2 og 3.

Applikationer og integrationer i kategori 1 er de mest kritiske, mens de i kategori 3 er mindst kritiske.

Applikationer KategoriFORMS-brugergrænsefladen 1CHR Internet (chr.fvst.dk) 1Landbrugsindberetning.dk 1Svineflyt.fvst.dk 1ZOOR.fvst.dk 1VetStat 2VetReg 2CHR Rapporter (chrrap.fvst.dk) 3

Tabel 3.2. Fordeling af applikationer i kategorier af tilgængelighed.


6 / 1 9

Webservices KategoriGLRCHRWS CHR_besaetning-HentBesaetningsbruger 2GLRCHRWS CHR_besaetning-HentBesaetningsejer 2GLRCHRWS CHR_besaetning-HentBesaetningspraksis 2GLRCHRWS CHR_besaetning-HentStamoplysninger 1GLRCHRWS CHR_dyrlaege-HentOplysninger 1GLRCHRWS CHR_ejendom-hentCHRStamoplysninger 1GLRCHRWS CHR_ejendom-HentOplysninger 3GLRCHRWS CHR_ejendom-HentVeterinaereHaendelser 1GLRCHRWS CHR_ejendom-ListBesaetninger 1GLRCHRWS CHR_ejendom-ListEjendommeUdenBrugsarter 1GLRCHRWS CHR_ejendom-ListOplysninger 2GLRCHRWS CHR_ejendom-SoegStamoplysningerMedAdresseInfo

2

GLRCHRWS CHR_ejer-ListBesaetninger 2GLRCHRWS CHR_virksomhed-listEjendomme 3GLRCHRWS DIKO-besaetningListFlytninger 1GLRCHRWS DYR-besListAktOms 2GLRCHRWS DYR-besListMglAfgAndenBes 1GLRCHRWS DYR-besListMglAfgSlagtDestrukt 1GLRCHRWS DYR-besListUdstationeringer 1GLRCHRWS DYR-hentCKRoplysninger 1GLRCHRWS FVKOPL- bekraeftFvkOplysninger 1GLRCHRWS FVKOPL-hentFvkOplysninger 1GLRCHRWS Svineflytning-listAlleFlytningerIPerioden 1GLRCHRWS Svineflytning-listFlytninger 1GLRCHRWS Svineflytning-listNationer 3GLRCHRWS Svineflytning-sletFlytninger 3GLRCHRWS Svineflytning-uploadFlytninger 1

Tabel 3.3. Fordeling af integrationer i kategorier af tilgængeligheder.

For applikationerne og integrationerne gælder det, at den maksimale sammenhængende periode med utilgængelighed indenfor kategorierne 1, 2 og 3 ikke må overstige henholdsvis 2, 4 og 8 timer inden for den primære driftstid. Se tabel 3.4.

Kategori Timer1 22 43 8

Tabel 3.4. Maksimal sammenhængende utilgængelighed indenfor primær driftstid.


7 / 1 9

3.3. Bod ved manglende opfyldelse af servicemål: TilgængelighedSåfremt kravet om Systemets tilgængelig ved afslutning af en kalendermåned jf. afsnit 3.1, tabel 3.1 ikke opfyldes af Leverandøren, betaler Leverandøren en bod på kr. 25.000 kr. pr. måned dog maksimum 10 % af fakturabeløbet for den pågældende måned (sum af vedligeholdelse, videreudvikling og driftsafvikling).

Såfremt kravet om systemets maksimale uafbrudte utilgængelighed, i den primære driftstid jf. afsnit 3.2, tabel 4.4 ikke opfyldes, betaler Leverandøren en bod pr. påbegyndt time som utilgængelighed overskrides. Der betales kun for påbegyndte timer i den primære driftstid. Boden afhænger af, hvilken kategori den berørte applikation befinder sig i jf. tabel 3.5 nedenfor.

Kategori

Bodsbeløb

1 6000 kr.2 3000 kr.3 1000 kr.

Tabel 3.5. Bod ved uafbrudt utilgængelighed.

Hvis tilgængeligheden rammer flere applikationer samtidig, betales kun for den applikation, der har den højeste kategori.

Tidspunktet for utilgængeligheden tæller individuelt for hver applikation.

Eksempel 1:Systemerne A (kategori 1) og B (kategori 2) bliver utilgængeligt kl 10. Kl. 12.01 starter bodsbetaling på system A med 6.000 kr. per time. Såfremt system A er tilgængeligt kl. 14.01, starter bodsbetaling på system B med 3.000 kr. per time. Hvis system A stadig er utilgængeligt betales fortsat 6.000 kr. per time.

Eksempel 2:Systemerne A (kategori 1) og C (kategori 3) bliver utilgængeligt kl 10. Kl 12.01 starter bodsbetaling på system A med 6000 kr. pr. time. Såfremt system A er tilgængeligt kl. 9.31 den efterfølgende dag, starter bodsbetaling på system C med 1.000 kr. per time. Derudover vil boden for manglende tilgængelighed på 98 % i den primære driftstid blive udløst, hvis tilgængeligheden for system A ikke er genetableret ca. kl. 13:45, idet 3 timer og 45 minutters primær driftstid svarer til ca. 2 % utilgængelighed.

3.4. Håndtering af bodsbetaling for tilgængelighedEn måneds bodsbetaling kan reduceres med 50 % ved opfyldelse af samtlige servicemål i den efterfølgende måned. Bodsbetalingen kan reduceres yderligere med de resterende 50 % ved yderligere en månedsopfyldelse af samtlige servicemål.

Bod afregnes pr. løbende 3 mdr.


8 / 1 9

4. Support 4.1. Servicemål: Reaktionstider ved fejl i Systemet

Kundens krav til aftalt support tidsrum fremgår af tabel 4.1Tabel .

Type Minimum support tidsrum

Tilbudsgiver skal angive tilbudt support tidsrun

Kommentar

Support Mandag til fredag 08:00-16:30

Sager til support skal kunne afleveres hele døgnet.

Tabel 4.1. Kundens krav til aftalt support tidsrum.

Ved en kritisk fejl skal support samt udbedring af problemet dog fortsætte udover det nævnte tidsrum.

Leverandøren skal bistå Kunden ved opretholdelse af Systemets brugbarhed. Uanset om årsagen til en given fejlsituation entydigt kan henføres til Leverandøren, er denne forpligtet til at bistå ved løsning af fejlsituationen.

Leverandøren skal registrere indmeldelsestid og tid for påbegyndt løsning.

Reaktionstid for igangsættelse af fejlrettelse måles fra incident indmeldes til Leverandøren efter henvendelse fra Kunden, en af Kundens samarbejdspartnere eller en alarm fra overvågning. Såfremt incident er registreret uden for den primære driftstid, beregnes tiden for igangsat fejlrettelse fra førstkommende primære driftstid.

Ved indmelding af fejl gælder de i tabel 4.2 anførte reaktionstider:


9 / 1 9

Prioritet

Påvirkning af Systemets brug

Reaktionstid for igangsætning af fejlrettelse

Indsats til rettelse af fejl

Servicemål:Løsningstid for rettelse / opdatering leveret

Rapportering til kunden

1. Kritisk

1. Systemet eller dele af Systemet kan ikke benyttes eller kan kun benyttes af enkelte brugere.2. Forretningskritiske operationer kan ikke gennemføres, uanset at det kun rammer en enkelt bruger

Umiddelbart

Fejl-/datarettelse og implementering af løsning fortsætter, indtil fejlen er løst, også hvis det er uden for Leverandørens normalearbejdstid

Målet er, at rettelsesopdatering er leveret til Kunden inden for 8 timer

Hver 2. time – bl.a. med redegørelse for de tiltag og den ressourceallokering, der er indsat for at løse problemet, og den fremdrift, der gøres

2. Høj Flere brugere har begrænsninger i brugen af Systemet, som følge af fejl i Systemets funktionalitet eller data på enkeltsager, og begrænsningerne kan ikke omgås ved midlertidige løsninger

Inden 2 timer i normal arbejdstid fra 8:30-16:30 på hverdage

Fejl-/datarettelse og implementering af løsning fortsætter inden for Leverandørens normalearbejdstid.

Målet er, at rettelsesopdatering er leveret til Kunden inden for 1 døgn fra fejlrettelsens igangsætning

Dagligt, med mindre andet aftales

3. Normal

Flere brugere har begrænsninger i brugen af Systemet, som følge af fejl i Systemets funktionalitet eller data på enkeltsager, men begrænsningerne kan omgås ved midlertidige løsninger

Inden 2 arbejdsdage

Fejl-/datarettelse og implementering foretages inden for Leverandørens normale arbejdstid

Målet er, at rettelsesopdatering er leveret til Kunden inden for 1 uge

Efter aftale

4. Lav Mindre betydende fejl, som ikke hindrer brugen af systemerne, men

Efter aftale Efter aftale Efter aftale Efter aftale


1 0 / 1 9

Tabel 4.2. Reaktionstider ved fejl i systemet.

Leverandørens månedsrapportering skal indeholde status for håndtering af fejl jf. bilag 3 - Ydelsesbeskrivelse.


1 1 / 1 9

5. Vedligehold og videreudvikling 5.1. Servicemål: Reaktionstider ved behov for vedligeholdelse og

udviklingVed indmelding af vedligeholdelses- og udviklingsopgaver gælder de i tabel 5.1 anførte reaktionstider:

Kategori Procestrin ReaktionstidHasteændring Kunden anmoder

Leverandøren om en hasteændring. Ved en hasteændring forstås ændring, der har karakter af kritiske fejlrettelser. Omgående igangsætning af løsningsforslag samt risikovurdering

Hurtigst mulig – dog max.2 arbejdsdage

Systemændringer Kunden anmoder Leverandøren om estimat på udarbejdelse af en løsningsbeskrivelse

Leverandøren skal komme med estimat inden for én uge med mindre andet er aftalt

Kunden anmoder Leverandøren om udarbejdelse af løsningsbeskrivelse inkl. estimat for udvikling af en ændring

Leverandøren skal udarbejde løsningsbeskrivelse inden for 3 uger med mindre andet er aftalt

Kunden godkender estimat og anmoder Leverandøren om udvikling og implementering af løsning

Leverandøren skal påbegynde udvikling og implementering indenfor 4 uger med mindre andet er aftalt

Ny selvstændig funktionalitet/nye moduler

Løsning beskrives på baggrund af en række analysemøder og workshops. For disse løsninger udarbejdes selvstændigt aftalegrundlag

Efter aftale

Tabel5.1. Reaktionstider ved ændringer i systemerne samt nyudvikling.

Ændringer og fejlrettelser releases løbende i takt med at de bliver klar, dette for at minimere risikoen for fejl og utilsigtede konsekvenser for andre dele af Systemet. Leverandøren og Kunden sammensætter og gennemfører i samarbejde disse releases på baggrund af Kundens prioritering.

Leverandørens månedsrapportering skal indeholde status for håndtering af ændringsønsker, jf. bilag 3 - Ydelsesbeskrivelsen.


1 2 / 1 9

5.2. Servicemål: Overholdelse af estimater for vedligeholdelse og udviklingKunden kan vælge at aktivere dette servicemål for en given leverance. Kunden skal udtrykkelig gøre Leverandøren opmærksom på servicemålets aktivering inden Leverandøren påbegynder estimering af leverancen.

Der aftales et vederlagsestimat og en tilsvarende pris for leverancen. Leverandøren er leveranceansvarlig for leverancen.

Leverandørens estimat skal være detaljeret og tilgængeligt for Kunden, så det tydeligt fremgår, hvad estimatet omfatter.

Leverandørens vederlag fremkommer ved at multiplicere det faktiske antal forbrugte timer for de medarbejdere, der direkte medvirker til opgavens udførelse, med de angivne priser i Kontrakten og bilag 5 - Vederlag og betalingsplan.

Såfremt det faktiske tidsforbrug ikke afviger mere end 10 % i forhold til vederlagsestimatet, er prisen 100 % af de anførte priser i Kontraktens bilag 5 - Vederlag og betalingsplan

Såfremt det faktiske tidsforbrug overstiger vederlagsestimatet med (a) mellem 10 % og 20 %, og (b) med mere end 20 %, skal der beregnes følgende rabat til Kunden:

1. Såfremt det faktiske tidsforbrug overstiger vederlagsestimatet med mellem 10 % - 20 %, skal der beregnes en rabat til Kunden på 20 % af timeprisen for de pågældende timer. Dette indebærer, at prisen for de overskydende timer vil være 80 % af de anførte priser i Kontrakten.

2. Såfremt det faktiske tidsforbrug overstiger vederlagsestimatet med over 20 %, skal der for de timer der ligger over 20 % af vederlagsestimatet beregnes en rabat til Kunden på 30 % af timeprisen for de pågældende timer. Dette indebærer, at prisen for disse timer vil være 70 % af de ovenfor anførte timepriser.

Såfremt det faktiske tidsforbrug ligger under vederlagsestimatet er Leverandøren berettiget til at modtage følgende bonus fra Kunden:

Såfremt det faktiske tidsforbrug ligger under vederlagsestimatet skal Leverandøren modtage en bonus for hver ubrugt time i henhold til vederlagsestimatet, der ligger under dette. Bonussen skal udgøre 30 % af de i Kontrakten anførte priser.

Eksempel 1 – Overestimat:Leverandøren udarbejder et estimat over den af Kunden beskrevne opgave. Vederlagsestimatet udgør 400 timer til en timepris på 800 kr. Ved afslutning af opgaven opgøres det faktiske tidsforbrug til 480 timer svarende et 20 % overforbrug. Kunden er således berettiget til en rabat på de overskydende 80 timer. Timeprisen for de overskydende 80 timer ændres til 640 kr. per time.

Eksempel 2 – Underestimat:Leverandøren udarbejder et estimat over den af Kunden beskrevne opgave. Vederlagsestimatet udgør 400 timer til en timepris på 800 kr. Ved afslutning af opgaven


1 3 / 1 9

opgøres det faktiske tidsforbrug til 360 timer svarende et underforbrug på 10 % (40 timer). Leverandøren er således berettiget til bonus på 30 % af de ubrugte timer svarende til 9.600 kr.


1 4 / 1 9

6. Servicevinduer og batchvinduer

6.1. ServicevinduerÆndringer til Systemet kan gennemføres i perioder som anført i tabel 6.1.

Der vil i perioder være begrænsede muligheder for at implementere væsentlige rettelser / ændringer til systemet. Dette skyldes, at systemet i perioder benyttes intensivt til tidskritiske opgaver. Der vil som en del af samarbejdet mellem Leverandøren og Kunden skulle ske en afklaring af, hvordan servicevinduer specifikt skal fungere.

Ændringstype Tidspunkt for ændringens implementering

Minimum varsling fra Leverandørens side

Opdatering af standard changes, jf. ITIL’s definition heraf

Dagligt i tidsrummet 00:00 – 05:00

2 dage

Større og kritiske opdateringer (Patch af operativsystem, databaseplatform etc.)

0-4 gange pr. måned i tidsrummet lørdag 13:00 til mandag 05:00

1 uges varsel

Omlægning af miljøer, arkitekturer og services

1-2 gange om året i tidsrummet lørdag 13:00 til mandag 05:00

2 ugers varsel

Småændringer Efter aftale Efter aftaleTabel 6.1. Servicevinduer

6.2. Batchvinduer

Type Tidspunkt for afvikling Minimum varsling fra Leverandørens side

Alm. Batchkørsler Dagligt efter aftale IngenStørre Batchkørsler Dagligt i tidsrummet 21:00 –

05:00Efter aftale

Tabel 6.2. Batchvinduer


1 5 / 1 9

7. Servicemål – Reetablering af SystemetLeverandøren skal sikre, at der foretages daglig backup af alle relevante dele af miljøerne omfattet af Kontrakten, således at det er muligt at foretage en reetablering af Systemets vitale dele, som servere og databaser, og som minimum applikationer og integrationer i kategori 1 jf. tabel 3.2 og 3.3 med indenfor 48 timer i produktionsmiljøet.


1 6 / 1 9

8. Dokumentation8.1. Servicemål: Fremvisning af DokumentationKunden ønsker at sikre, at Systemets Dokumentation til hver en tid er opdateret og tilgængeligt for Kunden. Leverandøren skal på anfordring kunne fremvise opdateret Dokumentation af Systemet, herunder driftsdokumentation med et varsel på 20 arbejdsdage.

8.2. Bod ved manglende opfyldelse af servicemål: DokumentationVed manglende overholdelse af kravet for fremvisning af Dokumentation betaler Leverandøren en bod på 1.000 kr. pr. påbegyndt døgn til Dokumentationen fremsendes.


1 7 / 1 9

9. Svartider GLR/CHR databasen benyttes både til direkte opslag og som en integreret del af andre systemer, der benytter systemets tekniske grænseflader. Det er derfor væsentligt, at Systemets svartider til enhver tid lever op til fastsatte krav.

Konkret opstilles der en række svartidskrav, som Systemet skal kunne præstere. I tabel 9.1 er anført en række transaktionstyper, der skal svartidstestes og konkrete svartider, der skal opnås. De konkrete transaktioner, der repræsenterer de beskrevne transaktionstyper (jf. tabel 9.1), aftales mellem Kunden og Leverandøren efter kontraktindgåelse, men inden Systemets driftsafvikling overtages af Leverandøren. For gennemførelse af svartidsmåling i forbindelse med driftsprøve henvises til bilag 8 - Prøver.

Der gennemføres svartidsprøver i det eksisterende System på eksisterende infrastruktur. Systemet skal ved driftsprøvens afslutning som minimum have samme svartider.

Svartiderne for den enkelte transaktionstype for såvel det nuværende som kommende System skal opgøres og beskrives af Leverandøren i Driftshåndbogen. Det er op til kunden at beslutte, hvor ofte svartidsmålinger skal gennemføres.

Såfremt en svartidsmåling resulterer i, at svartiden på Systemet på den nye infrastruktur overskrides svartiden på den gamle infrastruktur med mere end 100 %, betragtes Systemet som utilgængeligt for Kunden, og Systemets driftstid, som beskrevet i afsnit 3.1, påvirkes som et resultat heraf.

Servicemål svartiderTransaktionstype Beskrivelse/ForudsætningerSimpel En forespørgsel med en konkret nøgleAlmindelig En oprettelse eller opdateringKompleks En forespørgsel med søgning der ikke er

specificeret med en konkret nøgle f.eks. søgninger på tværs

Konkrete transaktioner Svartid [udfyldes af Kunden og Leverandøren efter test i eksisterende system ]

[Simpel transaktion 1] [ ][Simpel transaktion 2] [ ][Simpel transaktion …] [ ][Normal transaktion 1] [ ][Normal transaktion 2] [ ][Normal transaktion …] [ ][Kompleks transaktion 1] [ ][Kompleks transaktion 2] [ ][Kompleks transaktion …] [ ]

Tabel 9.1. Krav til svartider.

Leverandøren må gerne stille værktøjer til rådighed for måling af svartider, som en integreret del af Kontrakten, alternativt vil målingen blive udført med et stopur. I beregning af


1 8 / 1 9

svartiderne indgår ikke dele, som Leverandøren ikke bærer ansvaret for. Leverandøren kan derfor ikke gøres ansvarlig for svartider i dele af systemerne, som Leverandøren ikke bærer ansvaret for. Det påhviler Leverandøren at påvise at Fejlen hidrører herfra.

9.1. Afviklingstider for batchkørslerDer gennemføres en række batchorienterede kørsler mod GLR/CHR databasen. Da afviklingstiderne for disse batchkørsler kan påvirke adgangen til Systemet og andre systemer med grænseflader til GLR/CHR, skal Systemet fremover som minimum kunne levere samme afviklingstider, som det eksisterende System.

I tabel 9.2 er anført en række kørsler, der skal afprøves. De konkrete kørsler aftales mellem Kunden og Leverandøren efter kontraktindgåelse, men inden systemets driftsafvikling overtages af Leverandøren. Der opsamles - inden Leverandørens overtagelse - afviklingstider på de aftalte kørsler. Ved systemets driftsprøve kontrolleres det, at afviklingstiderne er overholdt.

Batchkørsel Afviklingstid [udfyldes af kunden og leverandøren efter test i eksisterende system ]

[Kørsel 1] [ ][Kørsel [ ][Kørsel …] [ ]

Tabel 9.2. Krav til batchkørsler.


1 9 / 1 9

Documents

Bilag 6 - Servicemål_ver.1.17 · Web viewHvis system A stadig er utilgængeligt betales fortsat 6.000 kr. per time. Eksempel 2: Systemerne A (kategori 1) og C (kategori 3) bliver