Foto til artiklen Vilkår om oppetid og support i netaftaler
Foto af StockSnap på Pixabay

Telefoni og net

Vilkår om oppetid og support i netaftaler

Oppetid og support er centrale vilkår i en netaftale. Aftalen bør beskrive, hvad der måles, hvornår supporten er tilgængelig, og hvordan leverandøren skal reagere på fejl.

Dette er et redaktionelt pseudonym for udgivelsen, ikke en påstand om en uafhængigt verificeret personlig identitet. Oprindelig redaktionel kreditering: Redaktionen for Tjenester.

Hvorfor oppetid og support er centrale i netaftaler

Oppetid og support er centrale vilkår i en netaftale. Aftalen bør beskrive, hvad der måles, hvornår supporten er tilgængelig, og hvordan leverandøren skal reagere på fejl.

Vilkårene bør fremgå af aftalen og dens bilag. Her kan parterne tilpasse servicemodellen til systemets funktion og betydning for virksomhedens drift.

Centrale vilkår er definition og måling af oppetid, måleperiode og undtagelser samt supportens åbningstider, responstider, eskaleringsvej og eventuelle sanktioner. Bilag om service og oppetid kan samle disse punkter.

Aftalen kan bruge betegnelser som oppetidsdefinition, målemetode, måleperiode, undtagelser, åbningstid, responstid, løsningstid, kritikalitetsniveau, eskalering og sanktion. Det vigtigste er, at parterne definerer begreberne tydeligt i aftalen eller bilaget.

Et oppetidsniveau angives som en procentdel, for eksempel 99,9 %, og responstider og løsningstider knyttes til fejlens kritikalitet. Aftalen bør altid angive niveauet sammen med de betingelser, der gælder for det.

En servicemodel kan samles i en rækkefølge, der gør vilkårene lettere at læse: først definition og måling af oppetid, derefter supportens åbningstider, responstider og eskalering. Det gør det tydeligere, hvordan løfterne hænger sammen.

Oppetid: definition, måling og undtagelser

Først skal aftalen fastlægge, hvad der tælles som oppetid. Oppetid kan defineres som, at systemet svarer på en forespørgsel, at en bestemt funktion eller et modul er tilgængeligt, eller at brugeren kan gennemføre sin arbejdsopgave fra start til slut. De tre definitioner giver vidt forskellige resultater for samme nedbrud.

Valget bør afspejle, hvad virksomheden faktisk skal bruge systemet til. Aftalen bør derfor fastslå, hvilken funktion eller brugerrejse der måles, og hvad der gælder, hvis en integreret tredjepartskomponent svigter, mens selve systemet kører.

Dernæst skal målingen beskrives, så den kan efterprøves: hvem måler – leverandøren, kunden selv eller en ekstern overvågning, hvilket værktøj bruges, hvor ofte måles der, og hvilken periode dækker opgørelsen. Oppetid opgøres typisk som en procentdel af en aftalt måleperiode.

Både målefrekvens og periode påvirker, hvor følsom opgørelsen er over for korte nedbrud. Afklar også, hvor kunden selv kan se rå målinger, og om kunden har ret til at få dem udleveret ved tvist om et nedbrud. Uden adgang til måledata kan et oppetidsløfte ikke håndhæves i praksis.

En oppetid på 99,9 % svarer til en nedetid på 43 minutter og 12 sekunder om måneden og 8 timer, 45 minutter og 36 sekunder om året. Derfor bør niveauet læses sammen med definition, målemetode, måleperiode og undtagelser.

Springet fra 99 % til 99,9 % oppetid fjerner næsten 80 timers nedetid. Springet fra 99,9 % til 99,99 % giver kun 8 timer ekstra oppetid og koster ofte markant mere i redundans og bemanding.

En oppetidsprocent er værdiløs, hvis den ikke definerer, om den gælder 24/7 eller kun i arbejdstiden, og om planlagt vedligehold trækkes fra. Det bør derfor fremgå entydigt af aftalen.

Parterne kan aftale, hvilke hændelser der ikke tæller med i oppetidsberegningen. Det kan eksempelvis være planlagt eller nødvendig vedligeholdelse, fejl i kundens netværk eller udstyr, kundens egne ændringer, tredjepartsleverancer eller forhold uden for leverandørens kontrol. Aftalen bør præcisere, hvilke undtagelser der gælder.

Undtagelser bør være afgrænsede og kunne forklares. Aftalen kan for eksempel fastlægge, hvornår planlagt vedligeholdelse må finde sted, og hvilken dokumentation leverandøren skal give for en undtagelse.

Aftalen bør navngive de hændelser, der kan undtages, og beskrive, hvordan de vurderes. Den bør også angive, hvem der træffer vurderingen, og hvordan kunden får besked om planlagt vedligeholdelse.

Undtagelser i oppetidsberegning: Fordele og ulemper

  • FordelePlanlagt vedligeholdelse kan foretages uden at påvirke oppetidsmålingen. Gør drift stabil og forudsætningsvis.
  • UlemperHvis undtagelser er for bredt defineret, kan leverandøren undgå ansvar for virkelige nedbrud. Skaber risiko for uklarhed.

Supportvilkår: responstider, åbningstider og eskalering

Supportvilkår bygges typisk op af fire elementer: hvornår supporten er tilgængelig, hvor hurtigt leverandøren skal reagere, hvordan henvendelser klassificeres, og hvordan de eskaleres. Åbningstiderne angiver, om supporten er bemandet i normal kontortid, udvidet åbningstid eller hele døgnet. Det bør fremgå, om der er forskel på hverdage, weekender og helligdage.

Åbningstid og responstid skal fremgå af aftalen. Knyt tiderne til fejlens klassificering, og gør det klart, om de gælder uden for supportens åbningstid.

Support kan modtage henvendelser via telefon, e-mail eller en selvbetjeningsportal. Aftalen bør angive de tilgængelige kanaler og vilkårene for henvendelser uden for åbningstiden, så kunden ved, hvordan en fejl skal meldes.

Kritikalitetsniveauerne kaldes ofte P1 til P4: nedbrud på hele systemet, nedbrud på en central funktion, fejl med en arbejdsgang som workaround og mindre fejl eller spørgsmål. Prioritetsniveauet styrer, hvilke responstider der gælder, så aftalen bør fastslå, hvem der klassificerer, og om kunden kan kræve en anden klassificering.

Et supportniveau er en kombination af åbningstid, responstid og løsningstid. Responstiden bør knyttes til det enkelte kritikalitetsniveau; for kritiske problemer kan aftalen for eksempel sætte en maksimal svartid på 2 timer, mens mindre sager får længere frister. Aftalen bør også sige, hvordan en sag eskaleres, hvis fristen overskrides.

Skeln mellem responstid og løsningstid. En aftale kan for eksempel garantere 15 minutters responstid og 1-4 timers løsningstid for P1-sager, hvor et hurtigt svar alene ikke redder forretningen. Løsningstiden er, hvornår fejlen er afhjulpet, eller en brugbar omgåelsesløsning er etableret.

Aftalen bør sige, om der også er en forpligtelse til at rette fejlen, og hvad der sker, hvis fristen overskrides. Eskalering sikrer, at en sag ikke bliver liggende. Aftalen bør beskrive kontaktpunkter på begge sider, hvornår en sag flyttes til næste niveau, hvem der har ansvar på hvert niveau, og hvordan kunden undervejs får status.

Beskriv, hvem der modtager sagen først, og hvornår den sendes videre til et højere supportniveau. Aftalen bør også fastlægge, hvem der opdaterer kunden, hvis sagen ikke løses inden for den aftalte tid.

Aftal også, hvordan supportydelser dokumenteres og rapporteres – fx i en fast statusrapport med åbne og lukkede sager – så rapporterne kan bruges i kontraktstyringen.

Aftalen kan også sætte en øvre grænse for gendannelse, fx en Recovery Time Objective på 4 timer. Den viser, hvor hurtigt driften skal være genoprettet efter et nedbrud.

SKI's it-aftaler og servicebilaget

En organisation, der køber it via SKI, kan begynde med at afklare sine behov og undersøge, om en af SKI's it-rammeaftaler dækker dem. SKI anbefaler at orientere sig i rammeaftalerne og de tilhørende e-kataloger.

It-drift kan købes via SKI's 02.22 it-drift, hvor man for eksempel kan få cloud, datacenter, netværk og applikation. E-katalogerne giver overblik over de løsninger og produkter, der er tilgængelige på rammeaftalerne (SKI).

I nogle tilfælde er en organisation forpligtet til at bruge en SKI-aftale, hvis den dækker organisationens behov. Undersøg derfor både aftalens dækningsområde og de løsninger, der fremgår af e-kataloget (SKI).

SKI fremhæver, at organisationer kan købe software og it-driftsydelser på rammeaftaler, hvor konkurrencen allerede har sikret fordelagtige priser og vilkår. Om aftalen passer til virksomhedens behov, afhænger stadig af den konkrete leverance (SKI).

Det er servicebilaget, der omsætter rammeaftalen til konkrete forpligtelser. Kontrollér derfor, at bilaget angiver oppetidsdefinition, responstider og undtagelser for den leverance, virksomheden køber.

Når en mulig aftale er fundet, bør virksomheden kontrollere, om leverancen omfatter de funktioner og driftsydelser, den har behov for. Gennemgå også servicebilaget, så vilkårene om oppetid, support og rapportering passer til den valgte løsning.

Aftalen bør gøre forholdet mellem hovedtekst og bilag entydigt. En klar rangorden hjælper parterne med at afgøre, hvilket dokument der gælder, hvis to bestemmelser er uenige.

Tilpas aftalen til den leverance, der faktisk købes. Vilkår, som ikke passer til leverancen, kan gøre det uklart, hvilke forpligtelser parterne har aftalt om oppetid og support.

Et indkøbsgrundlag hjælper med at finde og vælge en løsning, mens aftalens servicevilkår beskriver leverandørens forpligtelser. Kontrollér derfor, at det endelige aftalegrundlag tydeligt angiver både oppetidsmåling og supportniveau.

Sikkerhedskrav og NIS 2 i drift og support

Sikkerhed er en del af vilkårene om drift og support, fordi leverandøren her får adgang til virksomhedens systemer og data. For omfattede virksomheder opstiller NIS 2 en række minimumskrav, som aftalen bør adressere. Sikkerhedskravene bør i øvrigt afpasses efter, hvor kritiske og følsomme data leverandøren får adgang til.

Sikkerhedskrav bør passe til systemets funktion og de data, leverandøren får adgang til. En aftale kan derfor stille forskellige krav til adgang og kontrol alt efter løsningens betydning og dataenes følsomhed. En certificering som ISO 27001 kan dokumentere leverandørens sikkerhedsstyring.

For supportdelen bør man aftale, hvordan leverandøren får adgang: om der bruges fjernadgang eller en fast integrationsløsning, om adgangen er tidsbegrænset eller permanent, hvem hos leverandøren der har adgang, og hvordan adgangen logges og dokumenteres. Det bør også stå klart, hvordan adgangen ophører, når samarbejdet ophører, eller når en medarbejder hos leverandøren skifter opgave.

For driftsansvaret bør grænsen mellem leverandørens ansvar og kundens eget ansvar beskrives sammen med det aftalte oppetidsniveau. En nedbrudsundtagelse, der dækker kundens eget netværk eller kundens egne ændringer, er samtidig en ansvarsafgrænsning. Den bør formuleres, så begge parter kan se, hvad de hver især hæfter for.

NIS 2 kræver, at signifikante hændelser meldes med early warning inden for 24 timer og en fuld rapport inden for 72 timer (ENISA/NIS2-direktivet). Aftalen bør sikre, at leverandøren varsler kunden hurtigt nok til at nå de frister.

Aftalen kan beskrive leverandørens supportadgang, logning og ophør af adgang. Kravene bør afpasses efter, hvor kritiske og følsomme de data er, som leverandøren får adgang til.

Kontraktstyring: følg op på oppetid og support

Vilkår om oppetid og support har ingen effekt, hvis de ikke følges op efter underskrift. De vilkår, der skal følges op, er oppetidsdefinition, målemetode, måleperiode, undtagelser, åbningstider og responstider. Det er dem, kontraktstyringen holder øje med.

Kontraktstyringen består af konkrete handlinger: indsamle leverandørens oppetidsopgørelser og supportrapporter og sammenholde dem med de aftalte niveauer, holde kvartalsvise møder og registrere afvigelser. Brug de sanktioner eller prisnedslag, aftalen giver adgang til, og hold styr på ændringer, nye versioner og genforhandlingsfrister.

Sanktioner ved overskridelse skal følges op som en del af kontraktstyringen. Aftalen kan kræve automatiske service credits, der krediteres på fakturaen ved dokumenteret brud, typisk 5-20 % af den månedlige fee. Det gælder både oppetidsniveauer og responstider.

Uden disse rutiner opdages gentagne overskridelser af responstider først, når virksomheden selv mærker dem i produktionen. Et praktisk greb er at knytte kontraktstyringen til de målinger, aftalen allerede foreskriver.

Det gør det også lettere ved genforhandling at begrunde, om oppetidsniveauet, responstiderne eller åbningstiderne bør justeres. Kontraktstyringen bør knyttes til de dokumenter, aftalen bygger på.

Kontraktstyringen bør følge oppetidsdefinition, målemetode, periode, undtagelser, åbningstider og responstider. Sammenhold leverandørens rapporter med aftalen, og brug de beskrevne procedurer ved afvigelser.

Process for kontraktstyring af oppetid og support

  1. Indsamling af rapporterLeverandørens oppetidsopgørelser og supportrapporter indsamles kvartalsvis.
  2. Sammenligning med aftalens niveauerRapporter sammenholdes med de aftalte opgørelser for oppetid og responstid.
  3. Genforhandling og justeringData bruges til at begrunde ændringer i niveau, tider eller undtagelser ved genforhandling.

Konklusion: vælg vilkår efter virksomhedens behov

Oppetid og support bør fastlægges efter, hvor kritisk systemet er for virksomhedens drift. Jo større betydning nedetid har, jo mere præcist bør aftalen definere, hvad oppetid er, hvordan den måles, hvilke undtagelser der gælder, og hvilke responstider og eskaleringsveje der knytter sig til de enkelte kritikalitetsniveauer.

En brugbar servicemodel beskriver definition, måling, måleperiode og undtagelser for oppetid samt åbningstider, responstider og sanktioner. Vilkårene skal passe til den konkrete aftale og systemets betydning for driften.

Standardaftaler giver et fælles afsæt. Det gør det lettere at forholde sig til de enkelte bilag. En IT-serviceaftale kan samtidig tilpasses virksomhedens konkrete behov.

Sikkerhedskravene bør afpasses efter, hvor kritiske og følsomme de data er, som leverandøren får adgang til. Det afgørende er, at vilkårene er formuleret, så de kan efterprøves: klare definitioner, en aftalt målemetode, en aftalt rapportering og løbende kontraktstyring. Det gør afvigelser synlige og håndterbare.

Vælg derfor niveau, tider og undtagelser efter systemets kritikalitet. Standardaftalerne giver et fælles afsæt, men de konkrete vilkår skal stå i bilaget.

Den samlede servicemodel bør gøre det muligt at læse, hvordan oppetid måles, og hvilke undtagelser der gælder. For support bør aftalen beskrive åbningstid, responstid, løsningstid, eskalering og konsekvenser ved afvigelser.

Mere fra Telefoni og net