Hvilke vilkår om oppetid og support er almindelige i netaftaler?

Hvorfor oppetid og support er centrale i netaftaler

Oppetid og support afgør i praksis, hvad en netaftale er værd, når systemet er i drift. Samtidig er det de vilkår, lovgivningen sjældnest regulerer. Advokat Michael Thiesen konstaterer, at der ikke findes en lov, der regulerer IT-aftaler som sådan, men at anskaffelse af hardware og i visse tilfælde standardprogrammel er omfattet af købeloven. Derfor skal oppetid, responstider og supportniveau aftales konkret; de følger ikke af en standardregulering, man kan læne sig op ad.

Derfor bruges standardaftaler ofte som fælles afsæt. Driftsaftale17 er en standardaftale for IT-drift, der ifølge d17.dk giver kunder og leverandører et fælles afsæt for, hvad en it-driftsaftale skal regulere, og dermed gør det mindre ressourcekrævende at indgå it-aftaler. IT-Advokater peger på, at der fra offentligt hold er udarbejdet en serie standardkontrakter for at sikre både kunder og leverandører i offentlige IT-samarbejder, og at K01 er en del af serien. Brancheorganisationen Danske IT-Advokater (DITA) har udarbejdet en standardkontrakt for indkøb af it-systemer leveret som Software-as-a-Service.

For en netaftale betyder det, at man kan tage udgangspunkt i en af disse aftaler og tilpasse de enkelte bilag – herunder bilagene om oppetid og support – til den konkrete driftssituation.

Oppetid: definition, måling og undtagelser

Først skal det fastlægges, hvad der tælles som oppetid. Aftalen kan definere oppetid 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, og valget bør afspejle, hvad virksomheden faktisk skal bruge systemet til. Spørgsmål til leverandøren: Hvilken funktion eller brugerrejse måles der på, og hvad sker der, 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 der måles, og hvilken periode opgørelsen dækker. Oppetid opgøres typisk som en procentdel af en aftalt måleperiode, og 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.

Endelig skal undtagelserne skrives eksplicit: planlagt vedligeholdelse, der typisk varsles i forvejen og falder uden for oppetidsberegningen; akut eller nødvendig vedligeholdelse; nedbrud, der skyldes kundens eget netværk, eget udstyr eller kundens egne ændringer; fejl i tredjepartsleverancer; og forhold uden for leverandørens kontrol. Hvert undtagelsespunkt bør have en modydelse: at planlagt vedligeholdelse lægges i tidsrum uden kritisk drift, at nedbrud af en vis varighed ikke kan undtages, og at leverandøren skal dokumentere, at undtagelsen er relevant. Spørgsmål til leverandøren: Hvilke undtagelser gælder, hvordan varsles planlagt vedligeholdelse, og hvem afgør, om en hændelse falder under en undtagelse?

Vigtige mål for oppetid og support i danske netaftaler

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 skal angive, om supporten er bemandet i normal kontortid, udvidet åbningstid eller hele døgnet, og om der er forskel på hverdage, weekender og helligdage. Det bør også fremgå, hvilke kanaler der kan bruges – telefon, e-mail, selvbetjeningsportal eller andet – og om der gælder andre vilkår for henvendelser uden for åbningstiden.

Fejlklassificeringen er kernen i supportaftalen. Kritikalitetsniveauer – ofte nedbrud på hele systemet, nedbrud på en central funktion, fejl med en arbejdsgang som workaround og mindre fejl eller spørgsmål – skal defineres, så begge parter kan bruge dem, og det bør fremgå, hvem der klassificerer, og om kunden kan kræve en anden klassificering. Klassificeringen styrer nemlig, hvilke responstider der gælder. Skeln mellem responstid og løsningstid: responstiden er, hvor hurtigt leverandøren kvitterer og begynder at arbejde på sagen; løsningstiden er, hvornår fejlen er afhjulpet, eller en brugbar omgåelsesløsning er etableret. Mange aftaler lover kun det første, så spørg leverandøren, 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. Aftal også, hvordan supportydelser dokumenteres og rapporteres – fx i en fast statusrapport med åbne og lukkede sager – så rapporterne kan bruges i kontraktstyringen. Spørgsmål til leverandøren: Hvem sidder på første niveau, hvornår eskaleres en sag videre, og hvordan får vi besked, hvis en sag ikke løses inden for den aftalte tid?

Standardaftaler som rettesnor for vilkårene

Som afsæt for vilkår om drift og support kan man blandt andet bruge Driftsaftale17, K01 og DITA's SaaS-standardkontrakt. Driftsaftale17 er en standardaftale for IT-drift, der skal give parterne et fælles afsæt for, hvad en it-driftsaftale skal regulere. K01 indgår i den serie standardkontrakter, der er udarbejdet fra offentligt hold for at sikre både kunder og leverandører i offentlige IT-samarbejder. DITA's SaaS-standardkontrakt er målrettet indkøb af it-systemer som Software-as-a-Service. Tilsammen dækker de tre forskellige leveranceformer: drift af et system, IT-anskaffelse i offentligt regi og et SaaS-abonnement.

Værdien af at starte med en standardaftale er især, at definitioner, ansvarsfordeling og bilagsstruktur allerede er gennemtænkt og formuleret neutralt, så forhandlingen kan samle sig om de vilkår, der er vigtigst for den enkelte virksomhed. Når udgangspunktet er på plads, tilpasses bilagene: servicedeskription med oppetidsdefinition og supportniveauer, prisbilag, ændringsprocedure og eventuelle sikkerhedsbilag. En almindelig IT-serviceaftale kan tilsvarende tilpasses virksomhedens behov og dækker ifølge CE-IT de ydelser, der har med IT at gøre.

Ved tilpasningen er der to ting at være opmærksom på. For det første bør aftalen have en klar rangorden mellem hovedtekst og bilag, så det er entydigt, hvilket dokument der vinder ved uoverensstemmelse. For det andet bør man ikke importere en hel standardaftale, hvis kun dele af den passer – ubrugte vilkår skaber let uklarhed om, hvad parterne egentlig har aftalt om oppetid og support.

Sammenligning af standardaftaler til IT-drift og support

Fordele og ulemper ved at bruge standardaftaler

Sikkerhedskrav 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. Sikkerdigital.dk anbefaler i rådet om at stille sikkerhedskrav til IT-leverandøren, at man taler med leverandøren om alle punkter, og at sikkerhedskravene kan variere efter, hvor kritiske og følsomme virksomhedens data er. Det giver et konkret udgangspunkt for at kalibrere kravene: en driftsaftale om et system uden persondata behøver ikke samme kontrolniveau som en løsning, der håndterer følsomme oplysninger om kunder eller borgere.

For supportdelen betyder det, at man bør 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 og bør formuleres, så begge parter kan se, hvad de hver især hæfter for.

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. ITB satte i artiklen «Har du styr på din kontraktstyring?» fra 16. oktober 2019 fokus på dette område og beskriver, at DAHL Advokatfirma til daglig hjælper både kunder og særligt it-leverandører med stort set alle aspekter af kontraktudarbejdelse.

Kontraktstyringen består i praksis af konkrete handlinger: indsamle leverandørens oppetidsopgørelser og supportrapporter, sammenholde dem med de aftalte niveauer, holde faste opfølgningsmøder, registrere afvigelser og bruge de sanktioner eller prisnedslag, aftalen giver adgang til, samt holde styr på ændringer, nye versioner og genforhandlingsfrister. 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. Hvis aftalen fastsætter, hvem der måler oppetid, og hvordan support rapporteres, findes den dokumentation, der skal til for at følge op. Det gør det også lettere ved genforhandling at begrunde, om oppetidsniveauet, responstiderne eller åbningstiderne bør justeres.

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.

Standardaftaler som Driftsaftale17, K01 og DITA's SaaS-standardkontrakt giver et fælles afsæt, der gør det mindre ressourcekrævende at indgå aftalen og lettere at forholde sig til de enkelte bilag. En IT-serviceaftale kan samtidig tilpasses virksomhedens konkrete behov, og 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, der gør afvigelser synlige og håndterbare.