Dataforeningens vedlikeholdskontrakt for programvare
Dataforeningens vedlikeholdskontrakt for programvare
Veiledning for kontraktsutarbeidelse
DEN NORSKE DATAFORENING
Versjon : 2.1
Dato oppdatert : 15.11.2010
INNHOLDSFORTEGNELSE
3
1.3 HOVEDENDRINGER I VERSJON 2 5
1.4 Bruksområde og beskrivelse av Vedlikeholdskontrakten 5
2 KONTRAKTSSTRUKTUR OG INNHOLD
6
7
3.2 Organisering og arbeidsform 7
3.3 Utarbeidelse av tilbudsforespørsel 8
4 SPESIFIKASJON AV PROGRAMVAREN
8
5 SPESIFIKASJON AV VEDLIKEHOLDSTJENESTENE
8
5.3 Øvrige vedlikeholdstjenester 9
5.4 Oppstarts- og avslutningsaktiviteter 10
5.5 Språk og arbeidslokaler 10
10
10
8 VEDERLAG OG BETALINGSBETINGELSER
11
8.2 Fakturering og prisregulering 11
9 SANKSJONSBESTEMMELSER OG REFUSJONSORDNINGER
11
1 Innledning
1.1 Formål
Dette dokument gir en kortfattet veiledning i bruk av Dataforeningens vedlikeholdskontrakt for programvare, heretter kalt vedlikeholdskontrakten.
Formålet med denne veiledningen er å gi en beskrivelse av anvendelsesområdet for vedlikeholdskontrakten og hvordan brukerne skal forholde seg ved inngåelse av vedlikeholdskontrakten.
Det er forutsatt at videreutvikling av programvaren reguleres av en separat rammeavtale for utviklingstjenester. Begrunnelsen for dette fremgår nedenfor og av veiledningen for rammeavtalen.
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. Versjon 3 av PS2000 kontraktsstandarden ble lansert i 2007 av Den Norske Dataforening.
Dataforeningen har gjennom Faggruppen for IT-kontrakter ansvaret for videre utvikling og forvaltning av PS2000 kontraktsstandarden og tilhørende kontraktsstandarder.
Kontraktsstandarder for programvareforvaltning ble lansert i 2002 og kontraktsstandard for IT-drift i 2006. Forvaltning av kontraktsstandardene er basert på følgende modell som dekker hele livssyklusen for en programvarebasert løsning:
Behovet for å utgi kontraktsstandarder for forvaltning, herunder vedlikehold og videreutvikling, er begrunnet ut fra følgende:
- Kostnaden ved forvaltning er over tid høyere enn utviklings- og leveransekostnadene
- Det finnes ingen andre kontraktsstandarder for videreutvikling i markedet
- Alle utviklede systemer er gjenstand for et kontinuerlig endringsbehov
- Det reelle funksjonalitetsbehov erkjennes ofte etter en tids bruk av en leveranse
Arbeidet ble gjennomført i 2001 og 2002 med en referansegruppe hvor både leverandører og kunder var representert. Referansegruppen bestod av representanter fra:
- Cap Gemini Ernst &Young
- IFS Norge
- TietoEnator Consulting
- aetat Arbeidsdirektoratet
- Computas
- Norske Skog
- Rikstrygdeverket
- EDB Fundator
- Hewlett-Packard Norge
- IBM Norge
- Kluge Advokatfirma
- Deloitte & Touche Advokater
- Rettsvesenets IT- og fagtjeneste
- Vinmonopolet
- PROMIS
- Xxxxxxxxxxxxxx Xxxxxx
I tillegg har medlemmer av Norsk Senter for Prosjektledelse deltatt gjennom representanter fra Statoil, Dovre International og Metier Scandinavia.
Arbeidet med å revidere vedlikeholdskontrakten, basert på erfaringer med bruk fra 2002 og frem til 2007, er gjennomført våren 2008 slik at versjon 2 kunne utgis i august 2008.
Revisjonen er foretatt av en arbeidsgruppe nedsatt av Dataforeningens styre for Faggruppen for IT-kontrakter, med representasjon fra både kunde-, leverandør- og rådgiversiden:
- Capgemini Norge AS
- Computas AS
- Forsvaret FLO/IKT
- Gjensidige Forsikring
- NAV Arbeids- og velferdsdirektoratet
- SIMONSEN Advokatfirma DA
- PROMIS AS
PROMIS AS ved Xxxxxx Xxxxxxxx har ledet arbeidsgruppen. I tillegg har kolleger i de ovennevnte organisasjoner og Xxxxxxxx Xxxxxxxx i Timebox AS fungert som referansegruppe og avgitt høringsinnpill.
Mer informasjon om Dataforeningen og faggruppens arbeid kan fås ved henvendelse til Den Norske Dataforening (xxx.xxxxxxxxxxxxxx.xx) eller PROMIS AS (xxx.xxxxxx.xx).
1.3 Hovedendringer i versjon 2
Basert på erfaringer med bruk av kontraktsstandarden i perioden fra den ble utgitt første gang i 2002 og frem til 2008, ble det definert følgende liste med forbedringsområder som nå er ivaretatt i versjon 2:
- Sentrale roller i leverandørens organisasjon er inkludert
- Reguleringen av feilretting er utvidet med avgrensninger av hva som ikke skal anses som feil, krav til reaksjonstid og tilkallingstid, loggføring samt utvidede krav i forbindelse med overlevering av feilrettinger
- Krav til leverandørens vedlikehold av dokumentasjon er definert
- Regulering av beredskapstjenester er utvidet
- Krav til leverandørens forpliktelser ved oppstart og avslutning av kontrakten er inkludert
- I reguleringen av kundens ansvar er krav i forbindelse med brukerdokumentasjon, arbeidslokaler og forvaltning av standard programvare og teknologi tatt inn.
- Krav til kundens etablering og opprettholdelse av tekniske miljøer er utvidet
- Administrative bestemmelser og sanksjonsbestemmelser er gjort mer nyansert
- Eksempler på kommersielle satser og andre tall som er gjenstand for forhandlinger er fjernet fra del III (bilagene); og i den grad det er behov for slike, er de tatt inn i denne veiledningen, som eksempler på normal praksis
Ellers er det kun foretatt noen mindre korreksjoner og justeringer.
Versjon 2.1 inneholder i tillegg endringer knyttet til regulering av lønns- og arbeidsvilkår, personopplysninger og informasjonssikkerhet.
1.4 Bruksområde og beskrivelse av Vedlikeholdskontrakten
Vedlikeholdskontrakten ivaretar vedlikehold av programvare som er utviklet eller tilpasset for kunden under et eget prosjekt. Selve programvaren kan bestå av både standardprogramvare og spesielt utviklet programvare. Vedlikeholdskontrakten er tilrettelagt for å etterfølge et utviklings- eller tilpasningsprosjekt regulert av PS2000 kontraktsstandarden. Imidlertid er det ingen forutsetning at PS2000 kontraktsstandarden er benyttet for å levere den programvaren som skal vedlikeholdes.
Vedlikeholdskontrakten skal brukes for vedlikehold av programvaren. Det innebærer at drift av programvaren eller drift av kundens IT-utrustning må reguleres i egen avtale.
Vedlikeholdskontrakten dekker heller ikke endring eller videreutvikling av selve programvaren. Slike oppdrag kan partene regulere innenfor en separat rammeavtale for utviklingstjenester. Det er imidlertid ikke en forutsetning at det er inngått en separat rammeavtale for utvikling eller at samme leverandør leverer tjenestene på begge avtalene, men dette kan ofte være en fordel for å sikre et helhetlig forvaltningsregime. Dersom det er ulike leverandører, har begge leverandører plikt til å samarbeide slik at konsekvensene for vedlikeholdet hensyntas i rammeavtalen og vice versa.
Begrunnelsen for å skille videreutvikling og vedlikehold i to ulike avtaler er som følger:
- Vedlikehold fokuserer på å opprettholde programvarens funksjon og utnyttelse
- Videreutvikling benyttes for å dekke nye eller endrede behov og krav
- Ved å skille videreutviklingen fra vedlikeholdet blir det lettere å vurdere om videreutviklingen også krever endring i vedlikeholdstjenestene
- Vedlikehold tilbys ofte til fast pris, mens videreutvikling prises for hver oppdragsavtale basert på omfang, tilbud og risiko.
- En annen begrunnelse for å utarbeide separate avtaler for vedlikehold og videreutvikling er at kunden i mange tilfeller kan ha tilstrekkelig kompetanse til selv å vedlikeholde programvaren, men sjelden har kapasitet til å foreta videreutvikling dersom dette behovet blir omfattende.
Ettersom Vedlikeholdskontrakten er skreddersydd for programvarevedlikehold, gir den et godt utgangspunkt for å få en riktig strukturert avtale med regulering av de relevante tjenester knyttet til vedlikehold.
Vedlikeholdskontrakten er bygget opp med ”halvfabrikata” bilag. Dette både forenkler utarbeidelsen av bilag og legger til rette for at man regulerer alle de forhold som de generelle betingelser foreskriver skal være nærmere angitt i bilag.
For ytterligere å forenkle avtaleinngåelsen er det i bilagene satt opp forslag til detalj- regulering av tjenestene, eventuelt hvilke tjenester og forpliktelser som bør reguleres, og det er lagt inn forslag til ulike sanksjonsmekanismer.
2 Kontraktsstruktur og innhold
Kontrakten er delt inn i Del I Kontraktsdokument
Del II Generelle kontraktsbestemmelser Del III Bilag
Kontraktsdokumentet 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 en frihet til å velge form og innhold på dette overordnede dokumentet. Som et minimum må alle deler av kontrakten refereres og rangordningen mellom disse beskrives. Kontraktsdokumentet utarbeides når partene har oppnådd enighet om kontraktsbestemmelsene.
De generelle kontraktsbestemmelsene 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 kontraktens Xxx X.
De generelle kontraktsbestemmelsene inneholder:
- beskrivelse av leverandørens og kundens ansvar og plikter
- administrative bestemmelser
- beskrivelse av de ulike vedlikeholdstjenestene med referanse til spesifikk dokumentasjon i bilag
- endringshåndtering
- økonomiske vilkår
- juridiske bestemmelser, herunder sikkerhet, taushetsplikt, rettigheter, mislighold og avslutning av kontrakten.
Bilagene inneholder:
- oversikt over programvaren og alle komponenter som inngår, samt standard programvare og teknologi som er en forutsetning for å kunne vedlikeholde programvaren
- spesifikk dokumentasjon av vedlikeholdstjenestene:
o forebyggende vedlikehold
o feilretting (herunder hva som anses som feil og hvordan de skal håndteres)
o leveranse av nye versjoner av programvaren (herunder håndtering av standard programvare)
o dokumentasjon, brukerstøtte og opprettholdelse av kompetanse
o beredskapsordninger og eventuelt annen bistand til kundens forvaltning
o aktiviteter som skal gjennomføres ved oppstart og avslutning av Vedlikeholdskontrakten
o ansvar for standard programvare og teknologi samt de tekniske miljøene
- kundens ansvar og administrative forhold
- vederlagsmodell og forslag til sanksjonsmekanismer
Bilagene inneholder forslag til tekst som utdyper og eksemplifiserer spesifikke forhold rundt vedlikeholdsforpliktelsene. Bestemmelser som er avhengige av typen programvare og de krav kunden har til bruken av programvaren, er lagt til bilag basert på henvisning fra de generelle kontraktsbestemmelser. På de områder hvor de generelle kontraktsbestemmelser henviser til en spesifikk beskrivelse, men hvor ulike alternativer for en spesifikk beskrivelse kan være aktuelle, er det gitt en veiledning eller forslag til ulike former for regulering i
<klammeparenteser>. Tilsvarende er det gitt råd om hva som bør utdypes der det ikke er mulig å gi en generell anbefaling.
Det må påpekes at bilagsteksten må utfylles og gjennomgås grundig for å regulere spesifikke kontraktsforhold. I den sammenheng fungerer den foreliggende bilagsteksten ikke som en standard, men primært som en referanse fra de generelle kontraktsbestemmelser og som erfaringsbaserte eksempler på mulig innhold.
3 Forarbeid
3.1 Generelt
Ved forberedelse til inngåelse av vedlikeholdskontrakten, bør kunden inkludere følgende momenter:
- Finnes det relevante retningslinjer i gjeldende IT-strategi/virksomhetsplan?
- Hva finnes av egne ressurser og hva slags kompetanse har de?
- Ønsker kunden å bygge opp egen kompetanse, og kan deler av vedlikeholdet utføres av egne ressurser?
- Skal vedlikeholdskontrakten omfatte ett system eller en portefølje av systemer, vil det bli vesentlige endringer av omfanget i kontraktsperioden, og er omfanget for vedlikeholdsavtalen vel definert i forhold til kundens totale systemportefølje?
3.2 Organisering og arbeidsform
Kunden bør allokere dedikerte personer til å representere kunden overfor leverandøren, i tillegg til de roller som eksplisitt fremgår av vedlikeholdskontrakten. Dette fordi det er
nødvendig med et visst apparat for å forvalte arbeidet og følge opp leverandørens etterlevelse av vedlikeholdskontrakten.
3.3 Utarbeidelse av tilbudsforespørsel
Ved utsendelse av anbuds- eller tilbudsforespørsel bør de generelle kontraktsbestemmelser og bilag, så langt de lar seg utfylle fra kundens side, være inkludert som et grunnlag for potensielle leverandørers anbud eller tilbud. I offentlige anskaffelser må dette sees i sammenheng med lov om offentlige anskaffelser med tilhørende forskrifter, som igjen er basert på EØS-rettslige bestemmelser.
Uavhengig av om avtalen skal inngås i privat eller offentlig sektor, er det uansettfordelaktig for alle parter at tilbud innhentes på et så komplett grunnlag som mulig. Dette løses best ved at kunden, sammen med tilbudsforespørselen, sender ut kontraktsbestemmelser med bilag som er utfylt så langt kunden har mulighet til. På denne måten vil leverandørenes tilbud bli lettere å sammenholde og forhåpentligvis mer komplette.
Det anbefales at vedlikeholdskontrakt inngås samtidig med leveransekontrakt i de situasjoner det er ønskelig at samme leverandør som utvikler, tilpasser og leverer programvare også vedlikeholder den i etterkant.
4 Spesifikasjon av programvaren
Avtalens bilag 1 skal identifisere utviklet, tilpasset og standard programvare med tilhørende dokumentasjon som vedlikeholdstjenestene definert i bilag 2 skal knyttes til. I tillegg skal programvare og teknologi som er en forutsetning for vedlikeholdstjenestene identifiseres. Om nødvendig må det også avklares om vedlikeholdstjenestene skal knyttes til bruk av programvaren i ulike teknisk miljøer.
Dersom vedlikeholdsavtalen omfatter en portefølje av systemer, så kan systemene være i ulike livsfaser. Dersom systemer innenfor porteføljen nærmer seg fasen for minimalt vedlikehold, kan det være tilstrekkelig med en delmengde av vedlikeholdsytelsene eller med lavere kvalitetskrav for disse.
Dersom deler av systemporteføljen er utviklet med ulike varianter av teknologisk plattformer og utviklingsverktøy, bør det vurderes om det skal gjennomføres en konsolidering før vedlikeholdskontrakten etableres. Alternativt kan en slik konsolidering inngå som en del av oppstartsaktivitetene; ref. bilag 2.
5 Spesifikasjon av vedlikeholdstjenestene
5.1 Generelt
I avtalens bilag 2 er det sentralt for kunden på forhånd å ha tatt stilling til hvilket ytelsesnivå og hvilke forutsetninger som må kreves for vedlikeholdskontrakten. Det skal angis ønsket serviceperiode, eventuelt kan det angis noen alternativer som leverandørene kan gi tilbud på. Det kan være at leverandørene har standardiserte nivåer for serviceperiode og ytelsesnivå, og det kan derfor være kostnadsreduserende å la leverandørene tilby andre nivåer som opsjoner til kundens krav.
Flere av tjenestene som inngår i vedlikeholdstjenestene, vil kunne ha store variasjoner i innhold og disse må derfor underlegges en nærmere beskrivelse. Dette kan gjelde forebyggende vedlikehold, brukerstøtte og beredskap.
5.2 Feilretting
Når det gjelder feilretting, må kunden ta stilling til hvor rask reaksjonstid og tilkallingstid som er nødvendig. Kravene til tid bør settes avhengig av hvor kritisk programvaren er for kunden, typisk mellom ½-time og 4 timer for reaksjonstid og det dobbelte for tilkallingstid for A- og eventuelt B-feil.
Når feilretting er påbegynt er det også noen frister som partene må ta stilling til; hvilken frist leverandøren bør få for å kunne hevde at kunden har angitt uriktig feilkategori og hvor lang tid leverandøren skal forsøke å reprodusere en feil før tilleggsvederlag kan kreves. Typiske tider vil her kunne variere en del, men er normalt innenfor 8 timer, det vil si en arbeidsdag. Tidsangivelse før tilleggsvederlag kan kreves for reproduksjon av feil er typisk 4-8 timer.
Det mest sentrale kravet til tid, som kunden må ha tatt stilling til, er kravet til feilrettingstid. Det er normalt dette kravet det er knyttet sanksjoner til og som dermed er sentralt både i forhold til etterlevelse av kontrakten og for leverandørenes kostnadspåslag for vedlikeholdstjenestene.
5.3 Øvrige vedlikeholdstjenester
Når det gjelder nye versjoner av programvare er en standardformulering lagt inn, men denne kan endres ved behov.
Når det gjelder krav til å vedlikeholde dokumentasjon og kompetanse, må det spesifiseres mer konkret i forhold til type dokumentasjon og spesifikke kompetansekrav.
For brukerstøtte må det angis et antall timer som skal være inkludert i det faste vederlaget, eventuelt hvem som skal kunne benytte seg av denne, og hvor mange personer leverandøren minimum skal ha tilgjengelig for brukerstøtte. Her vil omfanget variere mye i forhold til behov, kundens egen kompetanse og bemanning. Det bør beskrives om dette er første-, annen- eller tredjelinje brukerstøtte, igjen avhengig av hva kunden selv har av bemanning og hva som er dekket av andre avtaler.
Tilleggstjenester er definert som konsulentbistand som kunden skal kunne bestille etter behov. Normalt er dette svært begrenset dersom det i parallell er en gjeldende rammeavtale for videreutvikling.
Når det gjelder beredskap er det foreslått noen reguleringer for utvidelse av serviceperioden og videre utvidet beredskap, noe som typisk er ønskelig i forbindelse med større produksjonssettinger. Her må det angis hvor mye tid som minimum kan belastes både ved tilkalling og telefonisk assistanse, typisk 2-4 timer henholdsvis 0,5-1 time. Utvidet beredskap skal avtales med et visst antall dagers varsel, typisk 5-10 arbeidsdager.
5.4 Oppstarts- og avslutningsaktiviteter
Oppstartsaktivitetene er normalt de aktivitetene som skal gjennomføres fra kontrakten signeres og til leverandøren overtar ansvaret for vedlikeholdstjenestene. Her er det behov for en grundig vurdering av hvordan dette skal gjennomføres, og da det i liten grad er etablert standarder for dette i markedet, er det her ikke foreslått konkrete reguleringer, men kun listet opp forhold som må inkluderes.
Dersom vedlikeholdskontrakten er en videreføring av en tidligere kontrakt som utløper, og avslutningsaktiviteter ikke er regulert i denne avtalen, er det viktig å etablere avtaleverk for å sikre seg støtte i oppstartsfasen fra den leverandør som eventuelt avslutter sitt avtaleforhold. Det må angis hvor lenge etter at kontrakten er opphørt, leverandøren plikter å tilby bistand til kunden, typisk 3-12 måneder.
5.5 Språk og arbeidslokaler
I et stadig mer internasjonalt leverandørmarked for vedlikeholdstjenester kan det være viktig å på forhånd ha avklart krav til språk og arbeidslokaler. Vedrørende språk kan det være ulike krav til ulike vedlikeholdstjenester avhengig av de kompetansekrav til språk en har definert for egne ansatte. Kravene til språk for brukerstøtte og installasjonsdokumentasjon kan for eksempel være annerledes enn kravene til detaljert systemdokumentasjon.
Vedrørende arbeidslokaler må det besluttes om vedlikeholdsaktivitetene skal foregå hos kunden eller i leverandørens lokaler. For mange leverandører kan det være aktuelt å bruke ressurser utenlands, og kunden må definere eventuelle forutsetninger for slik ressursbruk.
6 Kundens ansvar
I bilag 3 beskrives kundens ansvarsområder og grenseoppgangen mot leverandørens ansvar.
Kunden må beskrive hvilke former for dokumentasjon som kunden selv tar ansvar for. Den dokumentasjonen som leverandøren skal få ansvar for, må også beskrives. Videre må det fremgå om kundens arbeidslokaler skal benyttes av leverandøren og eventuelt behov for tilrettelegging.
For de ulike tekniske miljøene som kreves for vedlikeholdstjenestene, må det besluttes hvordan arbeidsdelingen mellom kunde og leverandør skal være. Dette kan også være relevant for standard programvare, for eksempel hvem som skal beslutte retningslinjer for bruk, og hvem som skal gjøre nødvendig basis konfigurering. For slike oppgaver er det nødvendig med en klar grenseoppgang og beskrivelse. I utgangspunktet har kunden ansvar for basis teknologi, men dette kan endres hvis ønskelig.
7 Administrative bestemmelser
I bilag 4 er det lagt opp til månedlig rapportering og månedlige møter mellom partene. Dette kan endres hvis ønskelig. I tillegg er det forutsatt at partene gjennomfører kvartalsvise møter hvor evaluering av kvalitet og etterlevelse av kontrakten står i fokus, og videre årlige møter hvor eventuelle endringer i kommende års vedlikeholdstjenester gjennomgås.
Ellers skal kundens og leverandørens kontaktpersoner angis i dette bilaget, i tillegg til leverandørens kritiske bemanning og underleverandører. Dette er normalt noe av det siste som fylles ut før signering.
8 Vederlag og betalingsbetingelser
8.1 Vederlagsmodeller
Vederlagsmodellen i bilag 5 må vurderes nøye for de enkelte elementer, og krav til sanksjoner må vurderes i forhold til både hvilken risikopremie kunden er villig til å betale og i forhold til hvilken verdi sanksjonene faktisk vil ha. For mer vurdering av bruk av sanksjoner og deres størrelse, henvises det til kapittel 9. Normalt vil vedlikehold prises til et fast vederlag per år, og i mange tilfeller vil vederlaget kunne være avtagende etter det første året.
Potensielle leverandører konkurrerer da på vederlagsnivå kombinert med pris på oppstartsprosjektet. Nye leverandører vil ofte måtte prise oppstartsprosjektet høyere enn eksisterende leverandør, noe som da må hensyntas i vurderingen av pris.
Timepriser skal også angis, men de benyttes normalt kun i forbindelse med tilleggstjenester. Videre må det angis hvordan beredskap skal prises i forhold til timeprisene. Typiske satser er 20-25 % av timepris ved hvilende vakt og 125-150 % ved utrykning utenom serviceperioden. Det må vurderes om satsene skal økes for søndager og offentlige høytidsdager.
8.2 Fakturering og prisregulering
Lengden på faktureringsperioden må fastsettes. Det er forutsatt at betaling skal skje tidligst midt i perioden for å unngå forhåndsfakturering.
Det må angis hvilken prisindeks som skal benyttes for å regulere prisene i kontrakten, fra når reguleringen kan gjøres gjeldende, og i tillegg til hvor lang tid i forkant prisregulering må varsles. Konsumprisindeksen er ofte benyttet, men andre alternativer som også kan benyttes, er lønnsindekser som Teknas lønnsstatistikk eller SSBs lønnsindekser for informasjonssektoren.
9 Sanksjonsbestemmelser og refusjonsordninger
Størrelsen på sanksjonene må, slik det fremgår av innledende tekst i bilag 6, tilpasses i forhold til hvilke sanksjonsordninger som kan iverksettes for samme forhold. Normalt vil kunden foreslå størrelsen på sanksjoner, men dette kan også benyttes som et element i konkurransen mellom leverandører. For høye sanksjonskrav kan medføre tilbud med forbehold eller unødvendig høy risikopremie på vedlikeholdsvederlaget.
Sanksjonene er i alle tilfeller relatert til en angitt sanksjonsperiode og vederlaget i denne perioden, typisk på 1 til 3 måneder.
I innledende tekst i bilaget er det også presisert at det er foreslått alternative sanksjonsmekanismer, som regulerer henholdsvis antall alvorlige feil og feilrettingstid. Dersom flere benyttes i samme kontrakt, bør størrelsen på refusjonene tilpasses dette forhold for å unngå utilsiktet dobbeltsanksjonering. Foreslått sanksjonsmekanisme knyttet til antall avdekkede feil, benyttes normalt bare når vedlikeholdet utføres av samme leverandør som har stått for utviklingen.