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 parterne er, og hvem der har hvilket ansvar. Den bør også fastlægge, hvad ydelsen omfatter, og hvad der falder udenfor. Endelig bør den beskrive, hvilke serviceniveauer der er aftalt, hvordan de måles, rapporteres og sanktioneres ved afvigelser, samt hvordan fejl, ændringer og exit håndteres.

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. 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. 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. Den er ikke et dokument, der først bliver relevant, når systemet er i drift.

Trin 1 i opbygningen er at fastlægge parter og ansvar. Trin 2 er at beskrive ydelsesomfanget og grænseflader. Trin 3 er at definere serviceniveauer, måling, rapportering og sanktioner ved afvigelser.

Trin 4 er at aftale dokumentationskrav, standardhenvisninger og licensvilkår. Trin 5 er at beskrive ændringshåndtering og exit. Den rækkefølge holder kravene tæt på både design og drift.

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

Standarder er anbefalinger og som udgangspunkt frivillige. Dansk Standard peger dog på tre situationer, hvor en bestemt standard ikke kan fravælges.

Det gælder, når love eller direktiver kræver, at bestemte standarder følges. Det gælder, når en virksomhed reklamerer med, at et produkt eller en ydelse opfylder en given standard. Det gælder også, 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 nævnes i aftalen, er den ikke længere et frivilligt referencepunkt, men et bindende krav. Leverandørens ydelse skal kunne dokumenteres op imod det. SLA'en bør derfor tydeligt angive, hvilke standarder der er aftalt, og hvad de skal bruges til.

Bruger man ikke de harmoniserede standarder, må man selv dokumentere sin løsning. Bruger man de standarder, der er udviklet til et bestemt direktiv, kan man nøjes med at henvise til dem i dokumentationen. Standarder bliver dermed 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), produktstandarder og prøvningsmetoder. Systemstandarderne beskriver, hvordan et produkt skal opbygges – fra byggeprojekter til IT-projekter. De 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.

Et dansk eksempel på standarder, der er gjort lovpligtige, er standarder refereret i Bygningsreglementet, herunder Eurocodes. I en SLA skal henvisningen derfor være præcis: nummer, udgave og formål.

Frivillige vs. bindende standarder i SLA'er

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 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. 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. Formålet kan være dokumentationsgrundlag, overensstemmelsesbevis eller 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.

Trin for trin betyder det, at du først vælger formål, derefter udgave. Skal standarden dokumentere overensstemmelse med et EU-direktiv eller en EU-forordning, kan en ophævet standard være den rigtige. Skal den give nyeste tekniske viden, vælger du den nyeste udgave.

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. Det drejer sig om 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 bør aftalen beskrive, hvordan journalisering og dokumentation understøttes teknisk. Den bør også beskrive, hvordan et afsendt dokuments integritet og autenticitet sikres, og hvordan afsenderidentifikation håndteres.

Ombudsmanden anbefaler desuden en forsvarlig tilrettelæggelse af nye it-systemer. Både formelle og materielle krav til sagsbehandlingen skal tænkes ind og overholdes i de forskellige forløb, sagerne kan tage. Det perspektiv kan med fordel afspejles i aftalens krav til test, dokumentation og ændringshåndtering.

De forvaltningsretlige regler omfatter bl.a. Forvaltningsloven; den blev ændret ved lov nr. 638 af 12. juni 2013 i lyset af offentlighedsloven. På offentlighedsområdet gælder Offentlighedsloven.

Offentlighedsloven – lov nr. 606 af 12. juni 2013, senere lovbekendtgørelse nr. 145 af 24. februar 2020 – regulerer bl.a. aktindsigt, journalisering, postlister, dataudtræk og meroffentlighed.

Offentlighedsloven gælder for statslige, regionale og kommunale myndigheder. Den gælder også for selskaber, hvor mere end 75 pct. af ejerandelene tilhører danske offentlige myndigheder, samt for KL og Danske Regioner. Efter lovens § 1, stk. 2, skal myndigheder sikre åbenhed ved valg, etablering og udvikling af nye it-løsninger.

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

Open source-software defineres ved sin licens. Den fællesoffentlige vejledning om brug af open source i den offentlige sektor siger, at open source-software er udgivet under en licens. Licensen giver enhver ret til frit og til ethvert formål at anvende, granske, tilpasse og videregive softwaren og dens kildekode.

Vejledningen understreger samtidig, at open source ikke handler om it-afdelingens teknologiske præferencer. Det er en strategisk forretningsmodel og nogle udviklingsmetoder, der styrker offentlige myndigheders medejerskab til deres løsninger. Det 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. Hvor det er relevant, kan de bruge bæredygtige open source-komponenter. Valget mellem open source og proprietære løsninger er ikke et enten-eller. Det handler om at vælge den løsning, der skaber værdi i forhold til myndighedens behov.

Vejledningen nævner udbredt open source i dansk offentlig sektor. Danske offentlige myndigheder bruger LibreOffice til tekstbehandling og QGIS til geodatabehandling. 82 kommuner bruger OS2kitos.

Åbne standarder er den anden halvdel af billedet. De fremmer konkurrence på softwaremarkedet. De gør det muligt for offentlige it-systemer at udveksle informationer på tværs, uanset hvilken software der er valgt. Vejledningen kalder dem 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 beføjelser får myndigheden over løsningen og dens kildekode – til at råde over, granske, tilpasse og distribuere den? 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.

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 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 fra myndighedernes ønske om at undgå afhængighed af bestemte leverandører og teknologier. Det kommer også 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 overdragelse af data, dokumentation, kildekode og rettigheder. Den bør også fastlægge, hvilken bistand leverandøren skylder i en overgangsperiode. Og den bør modvirke, at myndigheden bindes til leverandørens særløsninger.

Standarder og åbne formater letter overdragelsen. De fungerer som et fælles sprog, en ny leverandør kan arbejde ud fra uden at rekonstruere løsningen.

Trin for trin bør aftalen beskrive ændringsønsker, godkendelse, rettelsesdokumentation og kontrol af, at dokumentations- og identitetskrav stadig er opfyldt efter ændringer. Exit bør omfatte data, dokumentation, kildekode og rettigheder samt leverandørens bistand i en overgangsperiode.

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 beføjelser får myndigheden over software og kildekode – til at råde over, granske, tilpasse og distribuere dem? Hvordan håndteres tredjepartskomponenter og deres licenser?

– Æ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?

– Lovgrundlag: Offentlighedsloven gælder for statslige, regionale og kommunale myndigheder og for selskaber med mere end 75 pct. offentlig ejerandel. Den regulerer bl.a. aktindsigt, journalisering, postlister og meroffentlighed. Forvaltningsloven er også central.