Kontrakter og serviceaftaler: sådan opbygges en SLA

SLA'en som styringsværktøj – ikke bare et bilag

En SLA (Service Level Agreement) eller serviceaftale er ofte afgørende for, om en it-leverance fungerer i praksis. Den hører ikke hjemme som et bilag sidst i udbudsforløbet; den skal aktivt omsætte forretningens behov til ansvar, serviceniveauer og dokumentation. Aftalen bør derfor besvare: Hvem er parterne, og hvem har hvilket ansvar? Hvad omfatter ydelsen – og hvad falder udenfor? Hvilke serviceniveauer er aftalt, og hvordan måles, rapporteres og sanktioneres de, hvis de ikke overholdes? Hvordan håndteres fejl, ændringer og til sidst exit?

Tidspunktet er afgørende, fordi kravene skal kunne efterleves i driften. I sin myndighedsguide peger Folketingets Ombudsmand på, at indførelsen af digitale processer kræver planlægning, og at dårlig forberedelse og tidsoptimisme kan føre til fejl og mangler i it-systemerne med store konsekvenser for borgernes retssikkerhed. Ombudsmanden understreger samtidig, at fejl i et it-system sjældent rammer kun én borger: Skadevirkningerne mangedobles, fordi manglerne slår systematisk igennem, indtil de udbedres – og når først et mangelfuldt it-system er sat i drift, kan det være både svært og dyrt at rette op på.

For SLA-arbejdet betyder det, at krav til dokumentation, sikkerhed, test og ændringshåndtering skal formuleres, mens de endnu kan påvirke designet. Aftalen er altså et styringsværktøj, der rækker ind i udviklingen – ikke et dokument, der først bliver relevant, når systemet er i drift.

Standarder som aftalt reference: frivillige – indtil de står i kontrakten

Standarder er anbefalinger og som udgangspunkt frivillige at bruge. Sådan formulerer Dansk Standard det, og organisationen peger på tre situationer, hvor man alligevel ikke kan vælge en standard fra: når love eller direktiver kræver, at bestemte standarder følges; når en virksomhed reklamerer med, at et produkt eller en ydelse opfylder kravene i en given standard; og når en kontrakt eller mærkningsordning fastsætter, at en ydelse skal opfylde en eller flere standarder.

Den sidste situation er afgørende for en SLA. Når standarden først er nævnt i aftalen, er den ikke længere et frivilligt referencepunkt, men et bindende krav, som leverandørens ydelse skal kunne dokumenteres op imod. SLA'en bør derfor tydeligt angive, hvilke standarder der er aftalt, og hvad de skal bruges til.

Standarder har også en praktisk funktion i dokumentationen. Bruger man ikke de harmoniserede standarder, må man selv dokumentere sin løsning; bruger man derimod de standarder, der er udviklet til et bestemt direktiv, kan man nøjes med at henvise til dem i dokumentationen. Dermed bliver standarder et effektivt greb i en serviceaftale, hvor dokumentation af sikkerhed, funktionalitet og interoperabilitet ofte er et tilbagevendende stridspunkt.

Dansk Standard inddeler standarder i tre overordnede områder: designstandarder (systemstandarder), der beskriver, hvordan et produkt skal opbygges – fra byggeprojekter til IT-projekter – samt produktstandarder og prøvningsmetoder. Systemstandarderne er de mest oplagte at henvise til i en it-serviceaftale, fordi de beskriver, hvordan løsningen skal opbygges og dokumenteres.

Et aktuelt forbehold drejer sig om adgangen til standarderne: I sagen C-588/21 P – kendt som "Malamud-sagen" – har EU-Domstolen afsagt dom om aktindsigt i fire harmoniserede standarder. Domstolen stiller ikke spørgsmålstegn ved ophavsretsbeskyttelsen af harmoniserede standarder, men fastslår, at EU-Kommissionen ikke måtte afvise aktindsigt i den konkrete sag. Efter Dansk Standards vurdering er det endnu for tidligt at drage entydige konklusioner om dommens konsekvenser.

Vælg den rigtige standardudgave til formålet

En standardhenvisning er kun så præcis som den udgave, den peger på. Dansk Standard rejser selv spørgsmålet "Gældende eller harmoniseret?" og svarer, at det kort sagt afhænger af, hvad standarden skal bruges til: Ønsker man den nyeste viden på området, skal man vælge den nyeste udgave. Skal man derimod dokumentere overensstemmelse med et EU-direktiv eller en EU-forordning, er den nyeste udgave ikke nødvendigvis den rigtige at henvise til.

Dansk Standard gør samtidig opmærksom på, at man i visse tilfælde faktisk skal følge en ophævet standard. Forældede udgaver kan derfor være relevante, når formålet er at dokumentere overensstemmelse med en bestemt regulering – men de er ikke egnede, hvis formålet er at bruge den nyeste tekniske viden.

Harmoniserede standarder har en særlig status: De beskriver i detaljer, hvordan et direktivs overordnede krav kan opfyldes, de gælder i alle EU-lande og erstatter eventuelle nationale standarder. De er bestilt af EU-Kommissionen og knytter sig direkte til direktiverne. Ved at følge dem er man sikret at opfylde de væsentlige sikkerheds- og sundhedskrav i direktiverne, og de er med til at sikre produkters frie bevægelighed.

En SLA bør derfor ikke blot nævne et standardnummer, men fastlægge nummer, udgave og formål – altså om standarden bruges som dokumentationsgrundlag, som overensstemmelsesbevis eller som fælles teknisk reference. Aftalen bør også beskrive, hvad der sker, når en ny udgave afløser den aftalte, og hvem der har ansvaret for at beslutte og dokumentere et skift.

Krav til dokumentation, journalisering og identitet i offentlige it-serviceaftaler

For offentlige myndigheder er udgangspunktet klart: De almindelige forvaltningsretlige regler og principper gælder, uanset om sagsbehandlingen er manuel eller digital. Når hele eller dele af sagsbehandlingen digitaliseres og automatiseres, skal reglerne derfor fortsat overholdes. Det fastslår Folketingets Ombudsmand i sin myndighedsguide om generelle forvaltningsretlige krav til offentlige it-systemer.

Ombudsmanden peger på en række konkrete krav, som et it-system skal understøtte og sikre: journalisering og dokumentation af relevante sagsakter samt – for et afsendt brev – dets integritet og autenticitet, herunder entydig identifikation af afsenderen. Kravene gælder myndighedernes sagsbehandling, men har direkte betydning for, hvad der kan aftales med en leverandør i en serviceaftale.

Ombudsmanden understreger, at ansvaret for at efterleve kravene ligger hos den enkelte myndighed. I de senere år har Folketingets Ombudsmand i en del sager konstateret, at offentlige it-løsninger ikke har sikret overholdelse af de forvaltningsretlige krav. SLA'en kan og bør omsætte kravene til leverancekrav.

I praksis betyder det, at aftalen bør beskrive, hvordan journalisering og dokumentation understøttes teknisk, hvordan et afsendt dokuments integritet og autenticitet sikres, og hvordan afsenderidentifikation håndteres. Ombudsmanden anbefaler desuden, at en forsvarlig tilrettelæggelse af nye it-systemer sikrer, at både formelle og materielle krav til sagsbehandlingen tænkes ind og overholdes i de forskellige forløb, sagerne kan tage – et perspektiv, der med fordel kan afspejles i aftalens krav til test, dokumentation og ændringshåndtering.

Åbne standarder og open source: aftalevilkår der modvirker leverandørlåsning

Open source-software defineres ved sin licens. I den fællesoffentlige vejledning om brug af open source i den offentlige sektor står der, at open source-software er udgivet under en licens, der giver enhver ret til frit og til ethvert formål at bruge, undersøge, ændre og dele softwaren og dens kildekode. Vejledningen understreger samtidig, at open source ikke handler om it-afdelingens teknologiske præferencer, men er en strategisk forretningsmodel og nogle udviklingsmetoder, der styrker offentlige myndigheders medejerskab til deres løsninger og skaber bedre muligheder for at dele, videreudvikle og genbruge digitale løsninger.

Samme vejledning fastslår, at offentlige myndigheder så vidt muligt skal undgå løsninger, der skaber afhængighed af bestemte leverandører og teknologier, og at de hvor det er relevant kan bruge bæredygtige open source-komponenter. Valget mellem open source og proprietære løsninger beskrives ikke som et enten-eller, men som et spørgsmål om at vælge den løsning, der skaber værdi i forhold til myndighedens behov. Som eksempler på udbredt open source i dansk offentlig sektor nævner vejledningen bl.a., at danske offentlige myndigheder bruger LibreOffice til tekstbehandling og QGIS til geodatabehandling, og at 82 kommuner bruger OS2kitos.

Åbne standarder er den anden halvdel af billedet. De fremmer konkurrence på softwaremarkedet og gør det muligt for offentlige it-systemer at udveksle informationer på tværs, uanset hvilken software der er valgt – de er, som vejledningen formulerer det, det fælles sprog, systemerne bruger til at tale med og forstå hinanden.

For en SLA betyder det, at licensvilkår og rettigheder bør beskrives udtrykkeligt: Hvilke rettigheder får myndigheden til at bruge, undersøge, ændre og dele løsningen og dens kildekode? Hvordan håndteres tredjepartskomponenter og deres licenser? Og hvad sker der med rettighederne, når aftalen ophører? Ved at knytte svarene til åbne standarder som fælles reference bliver det lettere at skifte leverandør eller teknologi undervejs uden at genopbygge løsningen fra bunden.

Open source vs. proprietære løsninger: Fordele og udfordringer

Anvendelse af åbne standarder og open source i den danske offentlige sektor

Drift, ændringer og exit: aftal hvordan kravene holder

En SLA's værdi står sin prøve i driften. Aftalen bør derfor beskrive, hvordan ændringer og fejl håndteres løbende: hvordan ændringsønsker prioriteres og godkendes, hvordan rettelser dokumenteres, og hvordan man sikrer, at krav – herunder dokumentations- og identitetskrav – stadig er opfyldt efter en ændring.

Digitale løsninger bør bygges med henblik på genbrug og forandring. Det perspektiv kommer både fra myndighedernes ønske om at undgå afhængighed af bestemte leverandører og teknologier og fra Ombudsmandens pointe om, at kravene skal tænkes ind fra begyndelsen og overholdes i de forskellige forløb, sagerne kan tage. En SLA, der kun beskriver den nuværende konfiguration, bliver hurtigt forældet.

Exit er den del af livscyklussen, der oftest overses. Aftalen bør beskrive, hvordan data, dokumentation, kildekode og rettigheder overdrages, hvilken bistand leverandøren skylder i en overgangsperiode, og hvordan man undgår, at myndigheden bindes til leverandørens særløsninger. Standarder og åbne formater letter overdragelsen, fordi de fungerer som et fælles sprog, en ny leverandør kan arbejde ud fra uden at rekonstruere løsningen.

Tjekliste: sådan samler du SLA'ens byggeklodser

– Parter og ansvar: Hvem er aftaleparter, hvem har hvilke forpligtelser, og hvordan placeres ansvaret for de krav, myndigheden ikke kan aftale sig fra?

– Ydelsesomfang: Hvad er omfattet – og hvad falder udtrykkeligt udenfor? Beskriv grænseflader til andre systemer og leverandører.

– Serviceniveauer: Hvordan defineres, måles og rapporteres serviceniveauet, og hvad sker der ved afvigelser?

– Standarder: Hvilke standarder henvises der til, hvilken udgave, og hvad skal de bruges til – dokumentation, overensstemmelse eller fælles teknisk reference? Standarder er frivillige, indtil de står i kontrakten eller i en mærkningsordning.

– Dokumentations- og identitetskrav: Understøtter løsningen journalisering og dokumentation af relevante sagsakter samt integritet og autenticitet for afsendte breve, herunder entydig identifikation af afsenderen?

– Licens- og rettighedsvilkår: Hvilke rettigheder får myndigheden til at bruge, undersøge, ændre og dele software og kildekode, og hvordan håndteres tredjepartskomponenter?

– Ændrings- og exitprocedurer: Hvordan ændres aftalen, hvordan dokumenteres ændringer, og hvordan overdrages data, dokumentation, kildekode og rettigheder ved ophør?

– Forberedelse før idriftsættelse: Er kravene tænkt ind fra starten, så fejl og mangler ikke først opdages, når systemet er sat i drift, og det er svært og dyrt at rette op?