Af Christian Stage, Stage One Computing A/S

I teorien er serviceaftaler let tilgængelige og lige ud ad landevejen. Man får tilsendt en servicekontrakt fra en leverandør, man underskriver den og betaler en sum, og så er alting fint. Det er typisk lederniveau der sidder som underskriver, og med mindre noget er MEGET galt, hører de aldrig mere om aftalen. Virkeligheden er lidt mere kompleks og har flere detaljeringsgrader end som så – i hvert fald hvis man ønsker at have serviceydelser der fungerer.

Hvis virksomheden har bevæget sig ud i skyen eller har ekstern support på IT-ydelser, så har man også behov for en servicekontrakt. Hvis man ikke lige kan huske, hvad en servicekontrakt skal indeholde bliver kvaliteten af servicekontrakten som regel også derefter. Jeg vil således her forsøge at liste nogle faldgruber samt elementer, der bør indeholdes i en servicekontrakt.

Mange benytter den amerikanske term SLA eller Service Level Agreement. SLA kan måske være lidt vildledende, da den indikerer at man beskriver et kommercielt niveau (f.eks. guld, sølv, bronze – lidt ligesom statsbanerne i gamle dage havde første, anden og tredje klasse) mere end de praktiske ydelser, hvor ordet servicekontrakt i højere grad indikerer det reelle indhold: Nemlig at man til fulde beskriver de ydelser der leveres og det regelsæt, hvorunder de leveres. Lad os gøre det klart med det samme: Servicekontrakten benyttes i praksis kun når der er panik (der er jo kun behov for service, når tingene går galt, og produktionen står på nakken af vedligehold for at komme tilbage i drift), og den skal derfor være lysende klar, entydig og operativ, ellers spilder man tid og deraf produktion og penge. Ofte er det altså kun når noget virkelig brænder på, at servicekontrakten tages op af skuffen og støves af: den er ikke relevant ved diverse mindre serviceydelser.

Vær skeptisk

Hvis man får en ydelse leveret under en servicekontrakt kan det godt betale sig at være lidt skeptisk, før man skriver under. En klassiker kunne være en leverandør af en netværks- eller infrastrukturydelse, som

garanterer 98% oppetid. I første omgang lyder det fint, men når man dykker ned i aftalen, tager leverandøren ofte forbehold for planlagt nedetid. Ofte vælger leverandørerne at lægge planlagt nedetid i dagtimerne på hverdage, fordi IT-folkene er billigere i det tidsrum, og den eksterne support er bedre. Det passer desværre ofte dårligt med produktionen. Det duer heller ikke at leverandøren blot har en varselsperiode som de skal overholde, hvorefter de blot kan lave en planlagt fabriksnedlukning.  Produktionen er det væsentligste, og fabriksnedluk skal ALTID aftales nærmere og mere præcist.

Hertil kommer at 98% garanteret oppetid samtidig betyder en risiko for 2% uplanlagt nedetid. Hvis man regner med at et år som regel har 365 dage, og de fleste døgn har 24 timer, svarer det pludselig til at man kan have 7,3 døgns uplanlagt nedetid eller knap en halv times uplanlagt nedetid pr. døgn. Worst case kan det betyde at man mister op til 21 dages produktion om året. Så virker de 98% pludselig ikke så imponerende længere. Indenfor telebranchen køber man alle sine ydelser med en garanteret oppetid på 99,9999%, hvilket givere leverandørerne nøjagtigt to minutters nedetid til både planlagt og uplanlagt nedetid. Der er ingen rimelig grund til at en moderne IT-installation skulle være dårligere end hvad televerdenen har bedt sine leverandører om siden starten af 60erne. Det kræver mere forberedelse at levere høj oppetid, og er leverandøren ikke villig til at indgå en aftale om en sådan, så har de heller ikke forberedt sig godt nok: Ny leverandør søges!

En anden klassiker er supporttimerne. Som standard er det typisk 08-16 (eller sågar 09-17) support, men mange steder kører produktionen fra 06 – 18 eller 24/7 – hvad gør man så resten af timerne? Hvis produktionen er spredt over flere lande er problemet typisk større, da en fabrik på USA’s vestkyst dermed kun vil have support en eller nul timer i døgnet. Der findes også udenlandske leverandører der definerer supporttimerne til deres business hours, hvilket i praksis betyder at man ikke har support mere end fire timer pr. dag, hvis supportcenteret fx ligger i Kina.

Her spiller supportmetoderne også ind. Det er hundrede gange bedre, hvis man kan få en person i telefonen fremfor at skrive en mail, få autosvar og vente. Omvendt kræver telefonisk support at virksomheden på forhånd har overleveret basisinformation til leverandøren eller som minimum har en aftalt liste af informationer, man skal give sin leverandør. Hvis ikke virksomheden på forhånd har aftalt de specifikke informationer der skal udveksles, får   den ansvarlige medarbejder typisk en mængde spørgsmål fra supporten i stil med ”hvad er serienummeret på CPU’en i den maskine, der fejler?”. Denne type spørgsmål lyder fantastisk overbevisende, og de stilles i stedet for at teknikeren der befinder sig i den anden ende af telefonen skal sige ”Jeg ringer lige tilbage, når jeg er færdig med mit game”.

Ansvar

Ansvarsfordelingen skal fremgå soleklart af servicekontrakten. Der må ikke forekomme emner med delt ansvar: Hvis ansvaret er delt imellem to virksomheder er det altid den anden der skulle have gjort det (delt ansvar er i realiteten ensbetydende med at ingen har ansvaret). De i kontrakten definerede ansvarsområder understøttes i realiteten af procedurer, og hvis man ikke selv har en procedure der kan forklare, hvorledes ansvaret varetages, kan man ikke forvente at opgaven bliver udført. Ligeledes, når en leverandør har påtaget sig et ansvar, kan det være en god idé at auditere dem på, om de har procedurer der understøtter varetagelsen af ansvaret.

Husk i øvrigt altid at ansvaret ligger hos dig! Det kan være du har udliciteret en opgave til en ekstern virksomhed, men ansvaret overfor myndighederne flytter sig i praksis aldrig fra din virksomhed. Det er kun den operative del der kan flyttes.

Detaljer fremgår af vores hjemmeside

Mange leverandører er begyndt at henvise til uddybende information placeret på deres hjemmeside. DEN GÅR IKKE!

Hvis man skriver under på en serviceaftale, skal indholdet være dokumenterbart statisk, og det er helt sikkert en af de ting en leverandørkontrolleret hjemmeside ikke er. Hvis man skal acceptere indholdet fra en hjemmeside som en del af kontrakten, skal man som minimum overvåge den ved sammenligning op imod en statisk kopi man har i egen besiddelse.

Opdateringer til kontrakten skal ske hhv. ved ændringer i de services der leveres og på planlagte tidspunkter. Erfaringsmæssigt kan det godt betale sig at gennemgå og opdatere kontrakten ofte i den første tid. Dels vil der være services man alligevel skulle eller ikke skulle have haft og dels bliver man hurtigt klogere på, hvad en leverandør i praksis leverer. Senere, når den akutte situation er blevet mere normaliseret, kan man lægge sine opdateringer med større mellemrum (fx. hvert tredje år afhængigt af den type service, man køber).

Skal der stå mere?

Kontaktmetode

Som tidligere nævnt kommer servicekontrakten næsten altid kun i brug når der er panik på, og derfor er det en god idé at have veldefinerede kontaktmetoder. Hvis man benytter ”et system” som en del af sin kontaktmetode, skal brugen af dette være afprøvet og man skal vide, hvordan det virker. Det betyder samtidig at egne medarbejdere skal være passende trænede i at benytte systemet, og der skal opretholdes en rutine i brugen af systemet. Dette er en opgave der skal afsættes tid til, da mange servicesystemer ikke er specielt intuitivt opbygget.

Metoder for udveksling af data

Hvis leverandøren leverer en ydelse der fysisk ligger udenfor huset skal man lige huske myndighedskravene til valideret dataoverførsel. Metoden til dataoverførsel skal sikre dataintegriteten er bibeholdt og dokumenterbar, uanset hvor data er placeret.

Eskalering

Det skal også på forhånd aftales, hvorledes man fastsætter prioriteten af et problem. Ofte fastsættes ud fra antal påvirkede brugere, men det er måske mere relevant at sætte prioriteten ud fra om problemet kan påvirke data eller produktionen. Dataintegritet er af regulatoriske grunde naturligvis højt prioriteret, og virksomheden skal både kunne dokumentere at overførslen er gået godt, og at den løsning, man benytter, er valideret. Det er et myndighedskrav, at dataoverførsler kan dokumenteres som værende foregået korrekt. Dette gælder naturligvis dataoverførsel begge veje. Det vil sige, at der ikke kun skal kunne forefindes dokumentation for korrekt dataoverførsel, når denne lægges op i skyen, men i lige så høj grad, når/hvis data skal hentes tilbage og ned fra skyen igen (det sidste er der ofte en tendens til at glemme).

Hvis man ønsker at ændre prioriteten skal eskaleringsproceduren også være klar, og der skal være en mulighed for at ”folk på gulvet” kan ændre prioriteten, hvis problemerne forekommer udenfor normal arbejdstid eller ledere ikke er tilgængelige. De fleste medarbejdere (i hvert fald i Danmark) er fuldt ud modne til at vurdere, om prisen på et nedbrud overstiger den eventuelle ekstrapris, der måtte være på at øge prioriteten for en opgave hos leverandøren.

Audits og inspektioner

Eftersom man som virksomhed har flyttet opgaver ud til leverandører, kan man også forvente at myndighederne vil interessere sig for disse leverandører. Myndighederne kan bede om at se servicekontrakten, men de kan i princippet også bede om at komme på inspektion hos leverandøren. Man skal som virksomhed således betinge sig at leverandøren stiller sig til rådighed for inspektion. I tillæg giver det god mening, hvis man betinger sig at kunne auditere leverandøren samt at denne som minimum stiller et beredskab i form af folk med viden om servicekontrakt, de ydelser man leverer samt de procedurer og arbejdsrutiner, der benyttes i virksomheden. Hvis ydelsen der leveres er valideret skal man desuden kunne præsentere valideringsdokumentationen på en passende måde.

RPO/RTO

For en leverandør af en IT-relateret ydelse er RPO (Recovery Point Objective – det sidste tidspunkt, hvortil man kan reetablere data efter et nedbrud) og RTO (Recovery Time Objective – det tidsrum et IT-system kan være nede uden negativ påvirkning af produktionen) yderst vigtige emner der tilsammen er indikatorer for, hvor mange data og dermed hvor meget produkt man kan miste. Det er jo både vigtigt, hvor mange data man kan miste, og hvor lang tid man skal være foruden adgang til sin ydelse. Dette skal være baseret på en risikovurdering (som virksomheden har adgang til og evt. har godkendt) samt indgå i leverandørens Disaster Recovery Plan og Business Continuity Plan. De aftaler virksomheden har i servicekontrakten indgår naturligvis i virksomhedens egen Business Continuity Plan. Hvis ens egne mål fx er max fire timers datatab, og fire timers restoretid er det forholdsvis surt, hvis leverandøren af backup arbejder med 24 timers backupintervaller, og 12 timers restoretid. Sæt altid disse tidsrum op imod impact på produktionen og regn ud, hvor stor sandsynligheden er for at det sker samt, hvad det koster – Det er den slags virksomhedens ledelse elsker at godkende.

Husk desuden at hvis der laves restore ude hos en leverandør, skal det godkendes af systemets ejer (jer) på et passende niveau, det skal dokumenteres i en logbog I har adgang til, og hvis der er dataoverførsel tilbage til virksomheden, skal denne være valideret.

Forudsætninger

Ofte har leverandøren forudsætninger man som virksomhed skal opfylde, før de kan levere deres ydelse.  Det er vigtigt at man som virksomhed først kontrollerer at disse forudsætninger er på plads, før man melder en fejl til leverandøren. Hvis ikke forudsætningerne for serviceydelsen er i orden (har man fx kontrolleret om der er strøm på eller om adgangsbegrænsninger stadig er gældende), vil leverandøren ikke hjælpe, uanset om problemet er relateret til den forudsætning der ikke er til stede eller ej. Aftal derfor nøje, hvilke forudsætninger der er relateret til enhver mulig problemstilling så man kan sikre sig at få hjælp, når man har behov for det. 

En anden forudsætning er at alle definitioner er fuldstændigt klokkeklare. Er de ikke det, vil der altid være plads til fortolkning.  Handler det om IT-ydelser kan disse fortolkninger betyde forskellen på om noget er en del af leverancen eller ej, og om man overhovedet kan få hjælp i nødens stund. Det er fx ret vigtigt om en backup bare er nogle filer der ligger på leverandørens drev, eller om det er et veldefineret og verificeret sæt af nogle helt specifikke filer på et foruddefineret filshare.

Priser

Det kan anbefales at sørge for at alle ydelser og mulige tillægsydelser (fx ekstraordinær eskalering af et problem) er aftalt på forhånd. Man kan altid regne med at en serviceaftale er dyr, men da den skal holdes op imod hvad det koster selv at håndtere den samme ydelse, er det måske ikke så galt endda. Hvis det er en 24/7 ydelse der indeholder support skal prisen være realistisk dyr, og man skal være mistænksom, hvis prisen virker lav, da ydelsen så sikkert svarer overens med prisen. 

Hvis leverandøren ikke overholder kontrakten

Hvad så hvis leverandøren ikke overholder aftalen tænker du nok, men det svære er faktisk at finde ud af om de overholder aftalen. Som udgangspunkt kan leverandøren sandsynligvis levere den tekniske ydelse til UG, men som tidligere omtalt er det i nødens stund, man rigtigt kan få trykprøvet aftalen. Nogle af de advarselstegn som det er vigtigt at holde øje med kunne være, hvis man forbliver nummer et i en telefonkø når man ringer udenfor arbejdstid, eller hvis man får et autosvar på supportmailen og leverandøren ikke har givet lyd fra sig indenfor et forud defineret tidsrum.

Jeg havde selv en sjov oplevelse for nylig, da jeg en mandag morgen ringede til en leverandør angående et system, som de overvågede 24/7, og som havde været nede siden lørdag formiddag. Svaret fra supporten hos leverandøren var: ”Nu sidder vi jo ikke aktivt og overvåger det…”. Selvklart fik vi en god og opbyggelig samtale om definitioner af ”overvågning”, begrebet ”24/7” og ”responstid”.

Konklusion

Serviceaftalen (eller SLA’en) er altså meget mere end blot den ydelse eller service som leverandøren leverer. Det er dokumentet der sikrer compliance indenfor den del af virksomheden som den dækker. Den er desuden værnet imod nedbrud af produktionen, tab af data eller mistet dataintegritet.

Det er derfor tiden og diskussionerne værd at kigge dokumentet grundigt igennem og få talt detaljer på plads. Husk det er dig, der er kunden og dig, der betaler så det er også dig, der bestemmer. Det kan godt være at din leverandør er en stor virksomhed og fleksibiliteten ikke er i top, eller at de har et vidensniveau der er større end dit, men hvis ikke de kan (eller vil) opfylde dine krav, kan du blot vælge en anden leverandør.