Dataforeningens kontraktsstandard for IT-drift

Dataforeningens kontraktsstandard for IT-drift

Veiledning for kontrakts utarbeidelse

DEN NORSKE DATAFORENING

Versjon : 2.0

Dato oppdatert : 07.09.2011

INNHOLDSFORTEGNELSE

1 INNLEDNING 3

1.1 Formål 3

1.2 Bakgrunn 3

1.3 KONTRAKTSSTANDARD FOR IT-DRIFT, VERSJON 1 4

1.4 KONTRAKTSSTANDARD FOR IT-DRIFT, VERSJON 2 5

1.5 Bruksområde og beskrivelse av driftsavtalen 5

1.6 Sentrale prinsipper og begrep 6

1.7 Kontraktsstruktur 7

2 KUNDENS FORARBEID FØR INNGÅELSE AV DRIFTSAVTALEN 7

2.1 Vurdering av varighet 7

2.2 Valg av leverandør 7

2.3 Forutsetninger 7

2.4 Håndtering av endringer etter avtaleinngåelse 8

3 ETABLERINGSPROSJEKTET 8

4 KUNDENS OG LEVERANDØRENS EIENDELER 10

4.1 Oversikt over hva som skal driftes i henhold til driftsavtalen 10

4.2 Overtagelse av Kundens utstyr og programvare med mer 10

5 OM DRIFTSTJENESTENE 10

5.1 Relasjon til ITILs rammeverk 10

5.2 Om driftstjenestene 11

5.2.1 Tjenesteledelse 12

5.2.2 Drift av kundens applikasjoner 13

5.2.3 Drift av infrastruktur 13

5.2.4 Andre driftstjenester 14

5.3 Krav til tjenestekvalitet (SLA) og refusjoner 14

5.4 Prising i ulike faser 16

5.5 Håndtering av endringer til tjenestene 17

5.6 Brukerstøtte og øvrige tjenester 17

5.7 Tvisteløsning 18

5.8 Avslutning av driftstjenestene 18

1 Innledning

1.1 Formål

Dette dokument er en veiledning for bruk av Dataforeningens kontraktsstandard for IT-drift, heretter kalt driftsavtalen.

Innkjøp av IT-driftstjenester er en strategisk og viktig beslutning som innebærer at forretningskritiske operasjoner settes ut til en tredjepart. Dataforeningen har med denne bakgrunn utarbeidet en standardavtale for IT-drift som sikrer en målstyrt og balansert prosess for etablering og utførelse av driftstjenestene. Målsettingen med den nye driftsavtalen er at den skal ivareta morgendagens utfordringer ved utsetting av IT-driftstjenester, ved blant annet å fokusere på spesifikasjon både av prosessen og de ulike tjenestene.

Driftsavtalens formål er begrenset til drift av en IT-løsning, heretter kalt løsningen, som kan bestå av både utstyr og programvare. Vedlikehold og videreutvikling av løsningen må håndteres av separate avtaler og er derfor ikke inkludert i driftsavtalen.

Formålet med veiledningen er å gi en beskrivelse av bruksområde og fremgangsmåte for å få utbytte av driftsavtalen.

1.2 Bakgrunn

Høsten 1999 ble en ny kontraktsstandard for systemutvikling og systemleveranser, kalt PS2000 kontraktsstandarden, lansert. Kontraktsstandarden er ett av resultatene av et stort forskningsprogram - Prosjektstyring år 2000 (PS2000) - i regi av NTNU, SINTEF og sentrale aktører i næringsliv og offentlig forvaltning. En versjon 2 av PS2000 kontraktsstandarden ble lansert i mai 2001 av Den Norske Dataforening.

Det er videre i regi av Den Norske Dataforening utviklet en standard vedlikeholdskontrakt og en rammeavtale for videreutvikling som ble lansert første versjon i 2002.

Vedlikeholdskontrakten er utviklet for vedlikehold av programvare som er utviklet eller tilpasset for kunden under et eget prosjekt. Vedlikeholdskontrakten er tilrettelagt for å etterfølge et utviklings- eller tilpasningsprosjekt regulert av PS2000 kontraktsstandarden, men det er ingen forutsetning at PS2000 kontraktsstandarden er benyttet for å levere den programvaren som skal vedlikeholdes. Vedlikeholdskontrakten dekker heller ikke endring eller videreutvikling av selve programvaren, noe som istedenfor reguleres av en egen Rammeavtale for utvikling. Rammeavtalens formål er å regulere partenes forpliktelser og rettigheter i forbindelse med utviklingstjenester knyttet til den programvaren som er levert og vedlikeholdt i henhold til separate avtaler.

Porteføljen av kontraktsstandarder ble da i 2005 utvidet med kontraktsstandarden for IT-drift.

Dataforeningen har gjennom Faggruppen for IT-kontrakter, påtatt seg et ansvar for videre utvikling og forvaltning av alle disse kontraktsstandardene. Det komplette tilbudet fra Dataforeningen ser da slik ut:

Leveranse- omfang

Programvareforvaltning

….

Oppdrags- avtale n

Oppdrags- avtale 2

Oppdrags- avtale 1

Rammeavtale for utviklingstjenester (Videreutvikling, tillegg og endringer)

Vedlikeholdskontrakt

(Feilretting, brukerstøtte, beredskap og øvrig forvaltning)

Kontraktsstandard for IT-drift

Programvare utvikling/tilpasning

PS2000 kontraktsstandard eller annen utviklingskontrakt

Leveransetidspunkt

Livsløp

Selv om driftsavtalen inngår i en portefølje av kontraktsstandarder for programvareutvikling og -forvaltning, er driftsavtalen som det fremgår av punkt 1.1, likevel ikke begrenset til drift av kun programvare.

1.3 Kontraktsstandard for IT-drift, versjon 1

Arbeidet ble gjennomført av en arbeidsgruppe bestående av følgende personer:

Firma	Navn
PROMIS	Xxxxxx Xxxxxxxx (prosjektleder)
Aetat Arbeidsdirektoratet	Xxxxxxx Xxxxx Xxxx
EDB Business Partner	Xxxxx Xxx Xxxxxx
Xxxxxxxx Føyen Advokatfirma	Xxxxx X. Xxxxx
Xxxxxxxxxxxxxx Xxxxxxx Xxxxxx	Xxxxxx Xxxx
Xxxxxxxxxxxxxx Xxxxxxx	Xxxx Xxxx Xxxxxxxx
Xxxxxxxxxxxxxx Xxxxxx	Xxxx Xxxxxxxxx

I tillegg er det utvalgt en referansegruppe hvor både leverandører og kunder er representert. Referansegruppen har bestått av representanter fra følgende firmaer og offentlige institusjoner: Accenture, Aetat Arbeidsdirektoratet, Aker Kværner, Capgemini, Ciber, Computas, EDB Business Partner, Ementor Norge, Ergo Integration, Gjensidige NOR, Hewlett Packard, IBM, Norske Skog, Siemens, Skattedirektoratet, Statoil, Statskonsult, Steria og TietoEnator.

Videre vil vi spesielt takke Xxxxxx Xxxxxxx i Veritas og Xxxx Xxxxxxx i Ciber for verdifulle innspill under arbeidet med denne veiledningen.

1.4 Kontraktsstandard for IT-drift, versjon 2

Arbeidet med versjon 2 ble gjennomført i perioden juni 2010 til mars 2011 av en arbeidsgruppe bestående av følgende personer:

Firma	Navn
PROMIS	Xxxxxx Xxxxxxxx (prosjektleder)
Xxxxxxxxxxxxxx Xxxxxxx	Xxxxxx Xxxx
Departementenes servicesenter	Xxxx Xxxxxxxxx
Xxxx	Xxxx-Xxxx Xxxxxx Xxxxxx
EDBErgoGroup	Xxxx Xxxxxx
Logica	Xxxx Xxxxxx Xxx
NAV	Xxxxxx Xxxxxxx / Xxxxxx Xxxxxx Xxxxxxx
Xxxxxxxx Advokatfirma	Xxxxx Xxxxx / Xxxxx Xxxxx
Statens lånekasse for utdanning	Xxxx Xxxx Xxxxxxx
Xxxxxx	Xxxx Xxxx

Hele avtalen er utvidet med mer omfattende regulering av de ulike faser i livsløpet for en driftsavtale. Bilagene er i tillegg omarbeidet slik at det er tydeligere hva det må tas stilling til for å oppnå en god og balansert driftstjeneste. De generelle bestemmelsene er ellers oppdatert slik at regulereringer er samstemt med de øvrige kontraktsstandardene til Dataforeningen så langt det er hensiktsmessig.

Mer informasjon kan fås ved henvendelse til Den Norske Dataforening (xxxx://xxx.xxxxxxxxxxxxxx.xx) eller PROMIS AS (xxxx://xxx.xxxxxx.xx).

1.5 Bruksområde og beskrivelse av driftsavtalen

Driftsavtalen er utarbeidet av en bredt sammensatt gruppe av kunder, leverandører og uavhengige rådgivere og bør derfor kunne oppfattes som en partsnøytral kontraktsstandard.

Driftsavtalen leveres med ”halvfabrikata” bilag, noe som både forenkler utarbeidelsen av bilag og legger til rette for at alle de forhold som i henhold til de generelle betingelser skal avtales nærmere i bilag, blir regulert. For ytterligere å forenkle avtaleinngåelsen er det i bilagene satt opp forslag til detaljregulering av tjenestene, eventuelt hvilke tjenester og forpliktelser som bør reguleres og det er lagt inn forslag til ulike pris- og sanksjons- mekanismer. Tallverdier er ikke angitt, men det er gitt noen anbefalinger i denne veiledningen der det er funnet hensiktsmessig.

Driftsavtalen kan benyttes til å regulere følgende forhold mellom en kunde og en leverandør:

- Drift av IT-løsninger bestående av utstyr som maskinvare/servere og annen teknisk infrastruktur i tillegg til programvare

- Løsningene kan være både kundens og leverandørens eiendom

- Prosessene knyttet til både oppstarts- og etableringsprosjekt og til avslutning av avtalen

Driftsavtalen er ikke tilrettelagt for virksomhetsoverdragelse eller overtagelse av lisenser og medarbeidere, da regulering av slike forhold i liten grad kan standardiseres. Slike betingelser må derfor avtales ut fra den aktuelle situasjonen i separat avtale eller som tillegg til driftsavtalen.

Som det fremgår av ovenstående, må også vedlikehold og videreutvikling av applikasjons- programvare håndteres separat, gjennom egne avtaler.

1.6 Sentrale prinsipper og begrep

I utforming av driftsavtalen er følgende sentrale prinsipper og begrep lagt til grunn:

1. Fleksibilitet i forhold til tjenester og prising

En ryddig struktur i tjenestebeskrivelsen i form av en meny av tjenester.

Hver enkelt tjeneste fremkommer som et eget element og ikke sammenblandet med andre tjenester, noe som gir grunnlag for en fleksibel avtale. Det bør da være enkelt å identifisere alle relevante elementer som må endres dersom en tjeneste termineres, justeres eller legges til avtalen.

2. Forutberegnelighet i tjenester og prising

Det er tilrettelagt for at priser skal brytes ned på tjenestenivå for å sikre fleksibilitet, blant annet fordi dette synliggjør og skaper forutberegnelighet rundt eventuelle økninger eller reduksjoner i tjenestenivå.

Videre er det tilrettelagt for at leverandørens investeringskostnader skal kunne synliggjøres slik at leverandøren kan sikre at disse vil bli dekket og ikke må innkalkuleres i kostnaden for andre tjenester. I denne sammenheng må også eiendomsretten til utstyr og programvare hensyntas.

3. Tilrettelegging for åpenhet og visualisering

Grunnlaget for åpenhet og visualisering legges blant annet gjennom prismodellen, slik det er beskrevet ovenfor. Ytterligere synliggjøring oppnås gjennom klar definering av hvilken part som har eiendomsrett til utstyr og programvare i avtalen.

Det er tilrettelagt for kommunikasjon mellom kunde og leverandør gjennom fast rapportering og møteplikt i tillegg til opplysningsplikt. Dette skaper tillit og forutberegnelighet og bidrar til at problemer blir bekjentgjort og kan løses så tidlig som mulig.

4. Tvisteløsning med bruk av uavhengig ekspert

Det er tilrettelagt for tvisteløsning mellom partene gjennom oppnevning av en uavhengig ekspert. Den uavhengige eksperten skal kunne benyttes ved tvister av større omfang, blant annet dersom det ikke oppnås enighet om endringsanmodninger.

5. Bruk av incentiver og sanksjoner

Det er lagt opp til bruk av incentiver og sanksjoner på de områder som dette anses hensiktsmessig. Det er viktig å ivareta balanse på slike områder; begge parter skal kunne være fornøyd med prisnivået i driftsavtalen og skal kunne motiveres av det definerte incentiv- og sanksjonsnivået. Sanksjoner benyttes dersom leverandøren leverer en dårligere ytelse enn det som er avtalt, mens incentiver kan benyttes dersom kunden får en bedre ytelse enn det som er avtalt og kunden oppnår en merverdi av dette.

En forutsetning for å kunne benytte incentiver og sanksjoner effektivt, er at det kan foretas objektive og korrekte målinger.

1.7 Kontraktsstruktur

Driftsavtalen er delt inn i:

Del I Kontraktsdokument

Del II Generelle kontraktsbestemmelser Del III Bilag

Kontraktsdokumentet (Del I) består av en forside med nøkkelinformasjon om kunde, leverandør og inngått kontrakt, og er skilt ut som en egen del for å gi partene frihet til å velge form og innhold på dette overordnede dokumentet. Som et minimum må alle deler av driftsavtalen refereres og rangordningen mellom disse må beskrives i tillegg til driftsavtalens varighet. Kontraktsdokumentet utarbeides når partene har oppnådd enighet om de generelle kontraktsbestemmelsene og bilagene.

De generelle kontraktsbestemmelsene (Del II) skal kunne brukes med få eller ingen endringer, mens bilagene beskriver de spesifikke forhold for den enkelte kontrakt. Eventuelle endringer til de generelle kontraktsbestemmelsene skal fremgå klart av driftsavtalens Del I.

Bilagene (Del III) inneholder forslag til tekst som utdyper og eksemplifiserer spesifikke forhold rundt driftstjenestene. På de områder hvor de generelle kontraktsbestemmelsene henviser til spesifikk beskrivelse, men hvor ulike alternativer kan være aktuelt, er det gitt en veiledning til ulike former for regulering i <klammeparenteser>. Tilsvarende er det gitt noen råd om hva som bør utdypes der det ikke er mulig å gi en generell anbefaling.

2 Kundens forarbeid før inngåelse av driftsavtalen

2.1 Vurdering av varighet

Kunden må vurdere hvor lang oppsigelsesfrist som er nødvendig i forhold til omfanget av driftstjenestene. Dette må også ses i sammenheng med krav om midlertidig forlengelse som er en opsjon i avtalen.

2.2 Valg av leverandør

Ved utsendelse av konkurransegrunnlag eller tilbudsforespørsel bør de generelle kontraktsbestemmelsene og bilagene, så langt de lar seg utfylle fra kundens side, være inkludert som et grunnlag for potensielle leverandørers tilbud.

2.3 Forutsetninger

Det er sentralt for kunden på forhånd å ta stilling til hvilke tjenester og hvilket ytelsesnivå det er ønskelig at leverandøren skal ta ansvar for. Kunden bør ha dokumentert dette for sin egen del i en drifts- eller sourcingstrategi, som behandler følgende spørsmål:

- Finnes det retningslinjer i gjeldende IT-strategi/virksomhetsplan?

- Hva finnes av egne ressurser og hva slags kompetanse har disse?

- Ønsker kunden å bygge opp egen kompetanse?

- Hva gjør andre virksomheter og hva er deres erfaringer?

- Hvilke kostnader er knyttet til dagens drift og hvor godt fungerer det?

- Hvilket tilbud finnes i markedet for driftsutsetting?

- Hva vil konsekvensen av driftsutsetting være med hensyn til bemanning, kompetanse og sårbarhet?

- Hvilke trusler er forbundet med driftsutsettingen?

- Hvilke interne prosesser skal driftstjenestene tilpasses?

2.4 Håndtering av endringer etter avtaleinngåelse

I en driftsavtale vil det nesten uten unntak være nødvendig å foreta endringer etter avtaleinngåelse for å justere både krav og ytelsesnivå etter en tids erfaring med tjenestene. Det er derfor viktig at partene ved avtaleinngåelsen har tatt høyde for hvordan endringer i krav- og ytelsesnivå kan håndteres.

En måte å løse slike forhold på og som det er lagt opp til i standarden, er å definere tabeller for krav- og ytelsesnivå, slik at det er mulig å lese ut av tabellene hvilke konsekvenser endringer i krav- og ytelsesnivå vil få.

Andre endringer må håndteres enten ved at driftsavtalen oppdateres og ny versjon av driftsavtalen inngås og signeres eller ved at det opprettes en endringskatalog som beskriver alle endringer partene foretar etter avtaleinngåelse. For å gi frihet til valg av modell er det ikke innarbeidet mekanismer for slike endringer etter avtaleinngåelse.

3 Etableringsprosjektet

Driftsavtalen er delt inn i en etableringsfase, ordinær produksjon og en avslutningsfase. Dette kapittelet tar for seg etableringsfasen, men beskriver også noe rundt overgangen til ordinær produksjon. Etableringsfasen inneholder to sentrale milepæler, nemlig oppstartsdag og godkjenningsdag, og perioden mellom disse er definert som godkjenningsperioden.

Etableringsprosjektet omfatter både aktiviteter forut for oppstartsdag og i godkjenningsperioden frem til godkjenningsdag. Detaljer og fremdriftsplan fremkommer i bilag 4 til driftsavtalen.

I forbindelse med etablering av driftstjenestene skal det gjennomføres et prosjekt som inneholder de aktivitetene som er nødvendige for å kunne levere driftstjenestene, og hvor hver av partene er representert med sine prosjektledere. Leverandøren skal utarbeide planverket og lede prosjektet, men kunden forutsettes å bidra aktivt i dette arbeidet.

Etableringsprosjektet vil normalt inneholde aktiviteter som:

- planlegging

- undersøkelse av eksisterende eller etablering av ny infrastruktur

- installasjon av eventuelle maskiner og programvare

- installasjon av eventuelle verktøy og annen programvare

- installasjon av nettverk

- konfigurering

- utvikling og etablering av prosesser og arbeidsrutiner

- driftstest

- etablering av driftsorganisasjon

- prosjektledelse

- godkjenningsaktiviteter

Hvis løsningen som skal driftes allerede er i produksjon hos kunden, er det viktig at etableringen gjennomføres med minst mulig forstyrrelser, og at overgangen kan gjøres så sømløs som mulig.

Kunden skal i løpet av etableringsprosjektet godkjenne at den tekniske infrastrukturen tilfredsstiller de kravene leverandøren har stilt. Leverandøren skal på sin side tilrettelegge for og kontrollere at tjenestene er av en slik kvalitet at godkjenningsperioden kan igangsettes og gi kunden skriftlig melding om dette. Dette skal verifiseres gjennom en driftstest som leverandøren har ansvar for å gjennomføre.

Driftstjenestene skal leveres fra avtalt oppstartsdag og leverandøren skal gi kunden skriftlig melding om at tjenestene er igangsatt. Fra da av løper det en godkjenningsperiode. Dersom oppstartsdagen forsinkes med mer enn et avtalt antall dager, kan kunden kreve dagbøter som følge av forsinkelsen. Dette er en rett kunden har og som kunden selv velger å benytte.

Perioder angis i kontrakten i antall dager og ikke absolutte datoer slik at det ikke skal oppstå uklarhet i forhold til forsinkelse eller utsettelse av en milepælsdato og sanksjoner knyttet til tidligere faser.

Godkjenningsperiodens varighet må angis og vil typisk kunne være 1 til 3 måneder.

Partene må avtale hvorvidt driftstjenestene skal kunne tas i ordinær bruk av kunden i godkjenningsperioden, og hvilke begrensninger som eventuelt gjelder for slik bruk. I godkjenningsperioden bør endringer i løsningene begrenses så langt som mulig. Også her vil det etter et antall dagers forsinkelse, kunne kreves dagbot fra kundens side.

Leverandørens vederlag for godkjenningsperioden er omtalt under punkt 5.4.

Figuren under viser de to første hovedfasene og synliggjør samtidig de muligheter som forsinkelse i disse fasene gir i forhold til heving:

Etableringsprosjektet

Ordinær produksjon

Forberedelses- aktiviteter

Godkjennings- periode

Oppstartsdag

Godkjenningsdag

Evt. tilleggsfrist

Evt. tilleggsfrist

Dagbot i perioden og hevingsadgang

ved forsinkelse utover denne perioden

Dagbot i perioden og hevingsadgang ved forsinkelse utover denne perioden

4 Kundens og leverandørens eiendeler

4.1 Oversikt over hva som skal driftes i henhold til driftsavtalen

I tillegg til å spesifisere krav til driftstjenestene i bilag 1, må det også angis eksplisitt hva som skal driftes av leverandøren. Dette gjøres i bilag 2. SLA-kravene som det også kan kreves sanksjoner i forhold til, dersom kravene ikke nås, er nå samlet sammen med de standardiserte refusjonskravene i bilag 7.

Det er ikke lagt opp til at det spesifiseres hva leverandøren må investere i for å levere driftstjenestene. Utgangspunktet er at leverandøren selv må vite hva som er nødvendig for å utføre driftstjenestene, og at kostnadene for å anskaffe dette skal inngå som en integrert del av vederlaget og at det eventuelt skal være mulig å oppnå en fordel av stordriftskala hos leverandøren.

En annen sak er at det noen ganger er nødvendig eller hensiktsmessig å gi leverandøren tilgang til aktiva på kundens side. Dette gis det mulighet for i bilag 2, punkt 2.2. En normal forutsetning i dette punktet er at slik tilgang skal gis vederlagsfritt, og at tilgangen kun skal benyttes for å levere driftstjenestene.

4.2 Overtagelse av Kundens utstyr og programvare med mer

Kunden vil normalt ha risikoen for feil og mangler som må tilskrives kundens egne aktiva, eksempelvis feil i utstyr eller programvare som kunden eier. Ved å overdra aktivaene til leverandøren, oppnår kunden en risikooverføring til leverandøren.

Driftsavtalens bilag 3 kan benyttes for å fastsette nærmere betingelser for overtagelse av kundens utstyr og programvare med mer. Hvis overdragelsen får et stort omfang, er driftsavtalens bestemmelser antagelig for enkle til å regulere overdragelsen. I så fall anbefaler vi at det inngås en separat overdragelsesavtale i tillegg til driftsavtalen.

I bilag 3 er det lagt opp til at overføringen ikke skal være effektiv før etter godkjenningsdag. Dette er gjort fordi risikoen for hevning eller annen irregulær avvikling av driftsavtalen er mer sannsynlig i etableringsprosjektet enn i senere faser. Dersom overføringen ikke er gjennomført, blir det heller ikke nødvendig å reversere overføringen i forbindelse med en eventuell avvikling.

Det kan være fordelaktig å gi leverandøren bruksrett og eventuelt også ansvaret for forvaltning og administrasjon av slike aktiva allerede fra oppstartsdag. Dette skal i så fall spesifiseres i henholdsvis bilag 2 og 3.

Før det inngås avtale om overdragelse av kundens aktiva, og under enhver omstendighet før overdragelsen gjennomføres, bør kunden undersøke hva han har rett til å overdra. Det kan være at det er nødvendig å innhente skriftlig forhåndssamtykke fra en eller flere tredjeparter. Særlig kan dette være aktuelt i forbindelse med overdragelse av programvare og avtaler.

5 Om driftstjenestene

5.1 Relasjon til ITILs rammeverk

Information Technology Infrastructure Library (ITIL) er et rammeverk som i stadig større grad brukes for å etablere metodikk og prosedyrer for IT-drift.

Driftsavtalen fokuserer på å regulere forholdet mellom en kunde og en leverandør, og går i liten grad inn på hvordan tjenestene skal utføres og leveres. På relevante steder i bilag 1 kan

imidlertid kunden stille krav om at leverandørens kvalitetssystem skal være basert på ITIL og at leverandørens ressurser har kompetanse/sertifisering innenfor ITIL.

Spesifikasjonen av driftstjenestene i bilag 1 og beskrivelsen av tjenestene i kapittel 5.2 i denne veiledningen er i hovedsak bygget opp i henhold til elementene i ITILs rammeverk slik at det på høyt nivå skal være mulig å relatere tjenestene til dette rammeverket.

ITIL består av elementer som beskrevet i det etterfølgende (oversettelse i henhold til foreløpig resultat fra itSMF arbeidsgruppe i Norge).

V

i r k s o m h e t e n

Driftsstøtte for IT-tjenester

Sikkerhetsstyring

Håndtering av infrastruktur- styring for IT

Leveranse av IT-tjenester

Virksomhets- perspektivet

Applikasjonsstyring

Planlegging for å implementere ledelse av IKT-tjenester

T

e k n o l o g i

I tråd med dette er driftstjenestene i driftsavtalen delt inn i:

- Tjenesteledelse

- Drift av kundens applikasjoner

- Drift av infrastruktur

5.2 Om driftstjenestene

Nedenfor er det gitt en liste med mulige driftstjenester som kan inngå i en tjenestekatalog, sortert etter den inndelingen som er omtalt ovenfor. Innenfor tjenesteledelse er tjenestene også gruppert i forhold til den ITIL-prosess de relaterer seg til. De ulike oppgavene som er definert i punkt 5.2.1 er mer generaliserte, mens under punktene 5.2.2 og 5.2.3 er det definert mer spesifikke områder som kan dekkes av driftstjenestene. Videre er det tatt med noen forslag til øvrige driftstjenester i punkt 5.2.4. Ansvarskolonner (kunde/leverandør) bør benyttes for å bidra til bevisstgjøring om hva som skal være hver av partenes ansvar.

Referansefelt bør også benyttes for å kunne henvise til eventuell ytterligere beskrivelse som kan inntas i bilag eller annen dokumentasjon, noe som særlig er relevant dersom omfang, hyppighet/frekvens eller lignende skal spesifiseres. Opplistingen nedenfor er veiledende og utgjør således en mulig sjekkliste i forhold til hva som skal inngå i bilag 1.

I neste omgang må krav til tjenestekvalitet (SLA) vurderes. Krav til tjenestekvalitet skal fremgå av bilag 7. Tjenester med samme kvalitetskrav bør grupperes sammen for igjen å kunne referere til riktig krav til tjenestekvalitet.

5.2.1 Tjenesteledelse

Driftsstøtte for IT tjenester

- Incident Management

Registre feilmeldinger, bestillinger og forespørsler som sak

Klassifisere, undersøke og diagnostisere hendelser

Effektuere bestillinger og forespørsler

Feilretting

Allokere og sende teknisk personell til lokasjoner hvor feil har oppstått

Lukke sak i samråd med kunde/sluttbruker

Melde feil til leverandørens kundefront

Overføre sak til driftsstøtte

Overføre sak til underleverandør

Eskalere sak ved manglende fremdrift

Utføre brukeradministrasjon, herunder oppretting, endring og sletting av brukeridentiteter

Utføre sikkerhetsadministrasjon (brukere og data), herunder tilgangskontroll,

vedlikeholde autorisering og passordrettigheter

Ansvar for å administrere byttepool for brukerutstyr

- Problem Management

Dokumentere løsninger og omgåelse for kjente feil og problemer

- Change Management

Registrere og akseptere endringsanmodning

Klassifisere, godkjenne og planlegge endringsanmodning

Kontrollere og overvåke planlegging, utvikling, test og implementasjon av

endringsanmodning

Avklare godkjenning av endringsanmodning med kunden og der det er relevant fasilitere

beslutningsprosessen

Klassifisere, godkjenne, planlegge og gjennomføre hasteendring

- Release Management

Planlegge utrulling og produksjonssetting

Bestille og anskaffe programvare

Forberede pakking og klargjøring av programvare

Utføre funksjonstest og andre nødvendige tester

Gjennomføre opplæring og kommunikasjon i forbindelse med produksjonssetting

Gjennomføre utrulling og produksjonssetting

Lagerhold av reserveutstyr

Lagerhold av programvare, kildekode og dokumentasjon

- Configuration Management

Identifisere konfigurasjonsenheter samt fysiske og logiske relasjoner mellom enheter i en

konfigurasjonsdatabase

Gjennomføre løpende oppdatering av konfigurasjonsdatabasen ut fra endringer av

konfigurasjonsenheter eller relasjoner

Gjennomføre verifikasjon og revisjon av konfigurasjonsdatabasen

Lisensadministrasjon

Leveranse av IT tjenester

- Capacity Management

Identifisere potensielle forbedringer som kan resultere i økt kvalitet for tjenestene

Identifisere potensielle forbedringer som kan resultere i reduserte kostnader

Evaluere konsekvenser for kapasitet ut fra kundens varsel om endring i

virksomhetsprosess

- Availability Management

Etablere og etterleve rutiner og prosedyrer for å sikre kontinuerlig tilgang til tjenestene

Godkjenne retningslinjer for vedlikehold og reparasjon kundens utstyr

Definere retningslinjer for vedlikehold og reparasjon av kundens utstyr

- Service Level Management

Overvåke og rapportere om oppfyllelse av ytelseskrav for alle tjenestene

Gjennomføre regelmessig revisjon av kvaliteten på tjenestene i henhold til en omforent

kvalitetsplan

Benytte kundens garantier og vedlikeholdsavtaler med tredjepart for å minimalisere

reparasjons- og erstatningskostnader

- IT Service Continuity Management

Etablere og vedlikeholde en tjeneste for katastrofesikring og reservedrift

Gjennomføre regelmessig revisjon og test av katastrofeplaner

Sikkerhetsstyring

Autorisere tilgang til programvare og data

5.2.2 Drift av kundens applikasjoner

Utrulling; overvåke planlegging, utvikling og distribusjon av applikasjoner

Sjekke rapporter, avvik, databasekonsistens, komponentstatus

Regelmessig gjennomgang av status- og ytelsesrapporter

Overvåke løpende prosesser i applikasjonene

Overvåke og styre rutinemessige batchkjøringer

Delta på endringsmøter, vurdere og foreslå ytelsesforbedringer

5.2.3 Drift av infrastruktur

Overvåke alarmer og logger (inklusive sikkerhetsavvik og nettverkskomponenter)

Vurdere og analysere alarmer, logger og annen informasjon for å vurdere feilretting

Rette feil på komponenter

Installere og avinstallere komponenter (nettverk, tjenester, applikasjoner og programmer)

Starte og stoppe komponenter (nettverk, tjenester, applikasjoner og programmer)

Konfigurere og rekonfigurering av komponenter (nettverk, tjenester, applikasjoner og

programmer)

Slette filer og rotere logger

Vedlikeholde driftsdokumentasjon,

Reparasjoner, fjerning av defekte komponenter og innsetting av reparerte komponenter

Overvåke fysisk og logisk tilgang til IT-infrastruktur

Overvåke og styre rutinemessige batchkjøringer

Vedlikeholde databasesystemer

Levere avtalt lagrings- og datakapasitet, herunder å varsle kunden ved behov for endringer

Foreta optimalisering og justering av nettverk, maskinvare, lagringsutstyr og

systemprogramvare

Gjennomføre periodisk inkrementelle og fulle sikkerhetskopier og ved behov å utføre

gjenoppretting

Utveksle sikkerhetskopier (backup-taper) med fjernlagringsområde

Utføre daglig drift og vedlikehold av arbeidsstasjoner, skrivere o.l.

Foreta preventivt vedlikehold på kundens utstyr

I den grad det ikke er dekket av ovennevnte, må også følgende krav til driftstjenestene vurderes og eventuelt beskrives:

- Hvilke krav leverandøren skal oppfylle i forhold til sikkerhetskopiering, tilbakekopiering og gjenoppretting av data. Dersom manglende oppfyllelse av disse kravene, skal medføre eventuelle standardiserte refusjoner, må det fremgår av bilag 7.

- Eventuelle krav til leverandørens sertifiseringer og kvalitetssystem, herunder krav til ITIL-sertifisering, sikkerhetsklareringer, kvalitetssystem og kvalitetsstandarder som dekker den type tjenester som inngår i driftsavtalen.

- Krav til utarbeidelse og vedlikehold av driftsdokumentasjon og eventuelle krav til innhold og omfang.

- Krav til konfigurasjonsoversikt for utstyr og programvare inkludert sentrale parametere som inngår i driftstjenestene.

- Eventuelle spesielle krav som skal oppfylles knyttet til sikkerhet og tilhørende rutiner i forbindelse med driftstjenestene og de data som lagres i tilknytning til disse. Krav til behandling av personopplysninger skal fremgå av bilag 8.

- Eventuelt ansvar for vedlikehold og videreutvikling, og eventuelt med henvisning til andre avtaler.

- Hvilke rettslige eller partsspesifikke krav ut fra bransje- eller sektorspesifikt regelverk som har relevans for inngåelse og gjennomføring av driftstjenestene.

5.2.4 Andre driftstjenester

I tillegg kan det være behov for innkjøpstjenester, herunder å:

- godkjenne bestilling og bekoste anskaffelse av samband og nytt utstyr

- gjennomføre bestilling og anskaffelse av samband og nytt utstyr

Andre mulige tjenester som ikke er omtalt i det ovenstående, men som det kan være aktuelt å inkludere er:

- opplæring av kunden i relevante deler av driftstjenestene

- eventuelle spesifikke krav til leverandørens rapporteringssystemer, for eksempel feiloppfølgingssystemet

5.3 Krav til tjenestekvalitet (SLA) og refusjoner

En viktig del av konkretiseringen av driftstjenestene, og noe som oftest blir en sentral del av forhandlingene, er å avtale hvilke krav som stilles til de deler av tjenestene som er målbare hos kunden og som er de viktigste kravene som skal oppfylles. For kundene er dette normalt krav til tilgjengelighet, oppetid og responstid. Disse målbare kravene kalles normalt SLAer (Service Level Agreements). I bilag 7 er det listet opp noen av de mest typiske SLAer i en driftsavtale og disse er også beskrevet nedenfor.

Det må også defineres perioden for driftstjenestene, det vil si når driftstjenestene skal opprettholdes i form av en serviceperiode, som er definert som perioden fra klokkeslett om morgenen til kvelden på ordinære arbeidsdager (mandag - fredag) og en mer begrenset

periode øvrige dager og med eventuelle unntak for onsdag før skjærtorsdag og jul- og nyttårsaften.

Dersom det også er krav til opprettholdelse av driftstjenestene utenfor serviceperioden, må det fremgå av bilag 7. I så tilfelle kan det være nødvendig å duplisere med ulike krav innenfor og utenfor serviceperioden. Det samme behovet for duplisering gjelder dersom det er ulike krav til tjenestekvalitet for ulike driftstjenester.

Dernest er det viktig å avtale hvilke av SLAene som skal underlegges forhåndsdefinerte, standardiserte refusjoner ved manglende oppnåelse av kravene. Selv om en kunde ofte vil være interessert i å ha flest mulig og strengest mulig refusjoner ved brudd på SLAer, vil dette ha en prisdrivende effekt som kunden må hensynta. Videre kan det bli feil fokus dersom alle SLAer skal ha refusjoner. Normalt bør standardiserte refusjoner forbeholdes de SLAer som er de mest viktige for kunden slik at det heller ikke kan oppstå unødvendig dobbelt- sanksjonering. Hvilke dette er, vil være avhengig av kundens virksomhet. Et krav om standardiserte refusjoner vil kunne anses som en forsikringspremie som blir høyere jo flere krav som stilles.

Ved avvik i tilgjengelighet må det defineres en skala for når krav til refusjon oppnås, normalt fra 0,5 til 2,5 prosent og tilsvarende hvor høy refusjonen da skal være, normalt fra 5 og opp mot 50 prosent. Her må det også defineres grensen for hva som skal regnes som vesentlig mislighold. Normalt bør maksimal refusjon i 3 eller flere av de 6 siste avregningsperioder, være en slik grense.

Når det gjelder krav til antall driftsstans, vil refusjonen normalt være noe lavere for eksempel fra 2,5 til 10 prosent.

Ved avvik fra kravene til behandlings- og responstider må det også defineres en skala for når krav til refusjon oppnås. Her vil kravene kunne variere så vidt mye at det er vanskelig å definere normalverdier for skalaen. Størrelsen på refusjonen vil normalt være noe lavere enn den som er foreslått for tilgjengelighet. Behandlings- og responstidsmålingene vil normalt måtte foretas av leverandøren.

Et sentralt område er feilretting hvor det må defineres hvor raskt leverandøren skal påbegynne retting av meldte A- og B-feil. for eksempel kan kravet være innen henholdsvis ½ og 4 timer etter at feilen er meldt. Ved manglende oppfyllelse av kravene til reaksjonstid og feilrettingstid for A- og eventuelt B-feil i løpet av en avregningsperiode, skal det angis et refusjonskrav, som normalt vil være mellom 2,5 og 10 prosent for feilrettingstid og anslagsvis halvparten for reaksjonstid. Denne sanksjonen må vurderes mot sanksjoner knyttet til tilgjengelighet og driftsstans slik at de ikke blir overlappende. I tillegg er det slik at en kunde bør være varsom med sanksjoner knyttet til B-feil, da slike ofte blir håndtert samlet eller utsatt da de ikke representerer kritiske situasjoner.

Xxxxxxxxx samlede standardiserte refusjoner må være en andel av Vederlaget for Driftstjenestene i samme avregningsperiode. Det anbefales å legge dette på 50 - 60 prosent av vederlaget da det normalt er en del tjenester som ikke er rammet selv om krav om fulle refusjoner er oppnådd. Nivåene for de ulike områdene som sanksjoneres må ses i sammenheng med dette tallet.

Det er også mulig å avtale bonusordninger ved spesielt god og sikker drift; for eksempel dersom leverandøren har levert bedre enn SLA-kravene i en sammenhengende periode og dette har en merverdi for kunden. Slike bonuser kan fastsettes som konkrete beløp, men kan også, som ved refusjoner, utgjøre en prosentvis andel av vederlaget for den relevante tjeneste. Et normalt tak på slik bonus vil være 2-5 prosent av vederlaget.

For alternative måter å beskrive krav til tjenestekvalitet og for senere å kunne operasjonalisere kravene, vises det til Dataforeningens sjekkliste for tjenesteavtaler (SLA), se (xxxx://xxx.xxxxxxxxxxxxxx.xx).

5.4 Prising i ulike faser

De generelle kontraktsbestemmelsene (del II) er knappe i sin regulering av priser og betaling. I stedet henvises det til mer utfyllende reguleringer i bilag 6.

Overordnet har driftsavtalen tre faser som utløser vederlag:

1. Vederlag for etableringsprosjektet

2. Vederlag for godkjenningsperioden og

3. Vederlag for ordinær drift

Vederlaget for ordinær drift kan enten gjøres om en fast årlig avgift eller som en variabel pris avhengig av uttak. Erfaringsmessig kan en kombinasjon av disse mekanismene være egnet, ikke minst i de tilfeller der driftstjenestene omfatter mange, og til dels ulike komponenter (utstyr og programvare), og i de tilfeller hvor behovet for deler av disse tjenestene varierer over tid.

Det anbefales at prisingen gjøres fleksibel, forutberegnelig og åpen (se punkt 1.6). Hovedårsaken til dette er at det er hensiktsmessig å sikre at prisingen lett kan tilpasses et varierende tjenestebehov (fleksibilitet), at prisene enkelt lar seg kalkulere (forutberegnelighet) og at de reflekterer det økonomiske bytteforholdet korrekt mellom partene (åpenhet).

I forbindelse med ønsket om åpne og transparente priser, er det lagt opp til at det avtales et eget vederlag for etableringsprosjektet. Dette ut fra erfaringen at det ofte oppstår ønske fra kunden om at de kostnadene leverandøren har i denne fasen i stor grad bør tas av leverandøren ”på egen kappe” som en del av de forberedelser til oppstart av driftstjenestene. En slik løsning tilslører det reelle økonomiske bildet. For de tilfeller leverandøren ikke mottar eget vederlag for sitt arbeid i etableringsprosjektet, vil leverandøren måtte innkalkulere disse kostnadene i sitt øvrige pris-/kostnadsbilde og hente igjen det manglende vederlaget gjennom driftsavtalens øvrige priser. For øvrig må leverandøren normalt regnskapsmessig aktivere slike kostnader som en investering. For de tilfeller der kunden ønsker å fordele leverandørens vederlag for etableringsprosjektet i fasen for ordinær produksjon, kan dette gjøres, men bør da synliggjøres som et eget beløp i løpet av den første kontraktsperioden.

Når det gjelder vederlaget for godkjenningsperioden, legges det opp til et valg mellom et engangsvederlag eller en definert andel av det månedlige vederlaget for de ordinære driftstjenestene, noe som er spesielt aktuelt dersom det skal være reell drift i godkjenningsperioden.

For tilfeller av avbestilling og oppsigelse legger driftsavtalen til grunn at kunden, foruten å betale vederlag frem til avtalens opphør og et definert avbestillingsgebyr, skal betale leverandøren den andel av etableringsprosjektet som gjenstår til betaling. Denne regelen kommer naturligvis bare til anvendelse for de tilfeller der leverandørens vederlag for etableringsprosjektet er fordelt til betaling utover i den første kontraktsperioden. Størrelsen på det definerte, prosentvise avbestillingsgebyret kan beregnes ut fra normale nedriggings- kostnader, kostnader knyttet til investeringer i driftsperioden som ikke er nedbetalt og ikke kan nyttiggjøres, og eventuell kompensasjon for tapt fortjeneste som følger av kortere avtaleperiode.

5.5 Håndtering av endringer til tjenestene

Siden en driftsavtale gjerne vil løpe over flere år, er det stor sannsynlighet for at kundens behov for driftstjenester vil endres i avtaleperioden. Det er derfor viktig at partene har en metode for endringshåndtering som bidrar til å opprettholde den fleksibiliteten en driftsavtale ofte bør ha. I driftsavtalens del II, punkt 8, er det gitt regler om endringshåndtering.

Det første trinnet i prosessen vil normalt være at kunden fremsetter en endringsanmodning overfor leverandøren. Kunden kan kreve endring av de avtalte driftstjenestene, både i form av økning og reduksjon av omfang og innhold i tjenestene. Leverandøren har også rett til å fremsette endringsanmodninger dersom kunden ber leverandøren om å utføre noe som Leverandøren mener ikke er omfattet av driftsavtalen.

Neste trinn i prosessen er at leverandøren utarbeider en konsekvensutredning på bakgrunn av endringsanmodningen. Denne utredningen skal gi kunden et grunnlag for å kunne vurdere om endringen skal gjennomføres eller ikke.

Det siste trinnet i prosessen er at kunden, etter å ha vurdert leverandørens konsekvens- utredning, enten utsteder en endringsordre eller forkaster endringsanmodningen. Når begge parter har undertegnet endringsordren, skal endringen inngå i driftsavtalen på lik linje med øvrige betingelser.

Partene bør etablere gode administrative rutiner som sikrer at begge parter til enhver tid har oversikt over alle avtalte endringer. De som har ansvaret for kontraktsforvaltningen må samarbeide tett med de som har ansvaret for den løpende driften. Endringene må være skriftlig, slik at begge parter har dokumentasjon på hvilke endringer som er foretatt.

Dersom partene er uenige om det foreligger en endring eller konsekvensene av endringen, betraktes dette som en omtvistet endringsordre og skal håndteres etter driftsavtalens prosedyrer for konfliktløsning.

Alle endringer i driftsavtalens øvrige betingelser etter kontraktsinngåelse bør skje gjennom egne endringsavtaler. Endringsavtalen bør inkluderes i en endringslogg, som kan inneholde følgende:

- oversikt over hvilke dokumenter som er endret og eventuelle nye dokumenter

- hvilke vedlegg i dokumentet som er endret

- en kort beskrivelse av endringen

- nytt versjonsnummer på dokumentene listet opp i endringsavtalen

5.6 Brukerstøtte og øvrige tjenester

Når kunden overlater driften til en ekstern leverandør, kan det også være naturlig å la leverandøren yte brukerstøtte overfor kundens brukere. Kunden må i den forbindelse vurdere om hele brukerstøtten fra første linje og bakover skal overlates til leverandøren, eller om leverandøren kun skal benyttes i de tilfellene hvor det er behov for ekspertise og detaljert kunnskap om programvare og teknologi. Hvilken kompetanse kunden selv sitter med vil få betydning i valg av løsning. Hvor kundens driftsmiljø er plassert vil også spille en rolle i denne vurderingen.

En form for brukerstøtte vil være teknisk og funksjonell veiledning til brukerne av kundens IT-systemer. En annen viktig form for brukerstøtte er håndtering av feilmeldinger fra brukerne. Hvilken brukerstøtte leverandøren skal utføre må spesifiseres nærmere i bilag 1.

Det bør også avtales krav til tjenestekvalitet (respons- og behandlingstid) for brukerstøtten med standardiserte refusjoner ved brudd på disse kravene.

Et argument for å overlate driftsansvaret til en ekstern leverandør kan være at det gir kunden tilgang på bedre kompetanse og teknologi enn det kunden selv klarer å opprettholde. En profesjonell driftsleverandør kan også ha bedre forutsetninger til å se muligheten til forbedringer i kundens driftsmiljø. Driftsleverandører tilbyr gjerne rådgivning om effektiv utnyttelse og forbedringer i driftsmiljøet. Slik rådgivning kan enten være inkludert i de ordinære driftstjenestene eller tilbys som tilleggstjeneste.

5.7 Tvisteløsning

Den oppnevnte uavhengige eksperten får, etter å ha mottatt skriftlig innlegg fra partene, får en definert periode i form av et antall kalenderdager på å avgi sitt forslag til løsning for partene. Normalt vil dette være rundt 14 dager.

Dersom det skal gjennomføres megling, skal eksperten legge en plan slik at meglingen kan være gjennomført innen et antall kalenderdager, normalt rundt 30 dager.

5.8 Avslutning av driftstjenestene

Driftsavtalen skal i første omgang løpe i en tidsbegrenset kontraktsperiode. I denne perioden er det bare kunden som har rett til å si opp driftsavtalen mot å betale et avbestillingsvederlag. Etter utløp av den første kontraktsperioden, vil driftsavtalen løpe videre inntil en av partene sier opp driftsavtalen.

Når driftsavtalen blir sagt opp, vil kunden ha behov for bistand fra leverandøren for å sikre at avslutningen kan gjennomføres uten store driftsmessige ulemper for kunden. Driftsavtalen har derfor regler som pålegger leverandøren en plikt til å yte bistand til kunden i forbindelse med overføring av driftstjenestene til kunden, eventuelt til en ny driftsleverandør. Det anbefales å avtale vederlag for slik bistand.

Driftsavtalen forutsetter at partene avtaler frister for oppsigelse som gir tilstrekkelig tid til å foreta en ryddig overføring ved avslutning. I tillegg må kunden ha adgang til å be om forlengelse av driftsavtalen, dersom avslutningen må utsettes.