Dataforeningens rammeavtale om utviklingstjenester
Dataforeningens rammeavtale om utviklingstjenester
Veiledning for kontraktsutarbeidelse
DEN NORSKE DATAFORENING
Versjon : 2.10
Dato oppdatert : 105.11.201008
INNHOLDSFORTEGNELSE
1.3 HOVEDENDRINGER I VERSJON 2 5
1.4 Bruksområde og forhold til øvrige kontrakter 5
2 KONTRAKTSSTRUKTUR OG INNHOLD 6
4 BETINGELSER FOR UTVIKLINGSTJENESTER OG KONSULENTBISTAND 8
5 LEVERANDØRENS RESSURSER OG ANSVAR 8
1 Innledning
1.1 Formål
Dette dokumentet gir en kortfattet veiledning i bruk av Dataforeningens rammeavtale om utviklingstjenester, heretter kalt rammeavtalen.
Denne rammeavtalen er en selvstendig og fullverdig avtale, men den kan også inngås som et supplement til en separat vedlikeholdskontrakt.
Rammeavtalens formål er å regulere partenes forpliktelser og rettigheter i forbindelse med utviklingstjenester knyttet til programvare som er levert og vedlikeholdt i henhold til separate avtaler. Rammeavtalen benyttes når det er behov for å videreutvikle programvare over tid.
Omfanget av dette arbeidet vil variere, og utviklingstjenestene gjennomføres derfor som ulike oppdrag der disse nødvendigvis ikke behøver å være veldefinerte ved avtaleinngåelse.
Rammeavtalen legges da til grunn for hvert oppdrag. I tillegg kan rammeavtalen benyttes til å avrope konsulentbistand knyttet til programvaren selv om dette ikke medfører utvikling eller endring av programvaren.
Formålet med denne veiledningen er å gi en kort oversikt over Rammeavtalens bruksområde, struktur og innhold.
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 med første versjon som ble utgitt i 2002, ble gjennomført 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
- 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 rammeavtalen 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:
- Strukturen er endret slik at den blir mer lik de øvrige kontraktsstandardene
- Innholdet er utvidet slik at den blir en komplett avtale som kan fungere på selvstendig grunnlag
- Det er konsekvent skilt mellom to typer tjenester: utviklingstjenester i form av oppdrag og konsulentbistand
- Prismodellen er endret slik at den bygger på PS2000, samtidig som den er fleksibel
- Godkjenningsfasen er nærmere presisert og bygger på prinsippene i PS2000
- 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 forhold til øvrige kontrakter
Rammeavtalen er tilrettelagt for både videreutvikling av programvaren og tilhørende konsulentbistand. Den er basert på å etterfølge et utviklings- eller tilpasningsprosjekt regulert av PS2000 kontraktsstandarden. Imidlertid er det ikke en forutsetning at denne kontraktsstandarden er benyttet for å levere den programvaren som skal vedlikeholdes. For opprettholdelse av kravene til levert programvare kan den separate vedlikeholdskontrakten benyttes. Det er heller ikke en forutsetning at det er inngått en separat vedlikeholdsavtale
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.
Rammeavtalen 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
Rammeavtalen 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 rammeavtalen refereres, rangordningen mellom disse delene beskrives og varighet avklares.
Kontraktsdokumentet utarbeides når partene har oppnådd enighet om kontrakts- bestemmelsene.
De generelle kontraktsbestemmelsene skal kunne brukes med få eller ingen endringer. Alle spesifikke vilkår for den enkelte rammeavtale legges derfor til bilagene. Eventuelle endringer til de generelle kontraktsbestemmelsene skal fremgå klart av kontraktens Xxx X.
De generelle kontraktsbestemmelser inneholder beskrivelse av hvordan utviklingstjenestene gjennomføres i form av enkeltoppdrag basert på krav og betingelser til følgende områder:
- organisering av arbeidet
- gjennomføringsprosessen fra forespørsel, til tilbud og avtale om oppdrag, utvikling, installasjon, dokumentasjon og godkjenning av leveransen
- krav til gjennomføring av konsulentbistand
- økonomiske vilkår
- juridiske bestemmelser, herunder sikkerhet, taushetsplikt, rettigheter, mislighold, avbestilling og endringer
Bilagene inneholder
1. Spesifisering og gjennomføring av utviklingstjenestene og konsulentbistand
2. Leverandørens ressurser og forvaltningsansvar
3. Administrative forhold
4. Vederlagsmodeller
5. Xxx for oppdragsavtaler og oppdragslogg
For områder hvor de generelle kontraktsbestemmelsene henviser til en spesifikk beskrivelse, men hvor ulike alternativer for en spesifikk beskrivelse kan være aktuelle, er det i bilagene 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 Forutsetninger
Det er sentralt at kunden på forhånd har tatt stilling til hvilket ytelsesnivå og hvilke forutsetninger som må kreves for rammeavtalen.
Kunden må ta stilling til hvilke frister leverandøren gis og hvilke kompetansekrav som skal stilles til leverandøren.
Videre må administrative rutiner og krav til leverandøren presiseres, herunder føringer for gjennomføring, rapportering og møter.
3.2 Valg av leverandør
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.
4 Betingelser for utviklingstjenester og konsulentbistand
Bilag 1 inneholder en standardisert prosess fra kundens forespørsel til leverandørens tilbud og inngåelse av oppdragsavtale. Dersom denne benyttes uendret, er det kun behov for å angi en frist for leverandøren for svar på kundens forespørsler. Typisk frist er en uke, det vil si 5 arbeidsdager.
Det anses ikke å være behov for å utdype beskrivelsen i bilaget, utover at leverandøren må angi konsekvensene for vedlikehold i tilbudet, for senere å kunne kreve endring i vederlaget for vedlikehold.
Videre beskrives gjennomføringsprosessen i bilaget, fra leverandørens gjennomføring av utviklingsarbeidet og testingen til kundens godkjenningsprøve.
Her er ikke krav til testing utfyllende beskrevet, så det kan være behov både for å stille ytterligere krav eller la leverandørene beskrive sitt testopplegg.
Det må angis en frist for kundens godkjenning etter utløpet av godkjenningsprøven og videre om arbeidet skal utføres i kundens eller leverandørens lokaler.
Til slutt er også retningslinjer for konsulentbistand beskrevet. Konsulentbistand er arbeid som ikke medfører endring av programvaren. Her må frist for tilbakemelding fra leverandøren på ønsket bistand angis, typisk 5 arbeidsdager her også. Det må også angis en grense for hva som kan bestilles uten skriftlig forhåndsavtale; typisk bistand fra 10-20 timer.
5 Leverandørens ressurser og ansvar
I bilag 2 må kunden beskrive de ønskede konsulentkategorier og definisjoner til kompetansekrav. Typisk kreves det fra 2 til 10 års erfaring for de ulike kategoriene.
Leverandør skal liste opp kritisk bemanning. Det må angis en grense for hvor mange timer opplæring av nytt personale som eventuelt kan faktureres.
Under leverandørens forvaltningsansvar kan ytterligere krav til metoder og retningslinjer og videre til språk. Dette er særlig aktuelt dersom leverandøren har innført standarder for metoder og retningslinjer i egen organisasjon.
Leverandøren skal også angi underleverandører i dette bilaget.
6 Administrative forhold
I bilag 3 skal partenes kontaktpersoner angis.
Det er lagt opp til månedlig rapportering, og det må angis hvor lang frist leverandøren har etter månedsavslutning på å fremlegge rapport. Typisk frist er inntil 5 arbeidsdager. Det må også angis om det er behov for månedlige møter mellom partene eller om aktivitetsnivået er så lavt at det holder med kvartalsvise møter.
Det er til slutt i bilaget beskrevet hvilke situasjoner som skal kunne utløse krav om ytterligere tillegg i form av egen prosjektledelse for enkelte oppdragsavtaler.
7 Vederlagsmodeller
Kunden må vurdere om vederlag skal baseres på timeforbruk, målpris eller fast pris for ulike typer oppdrag basert på omfang og usikkerhet for oppdraget. For oppdrag basert på målpris må kunden ta stilling til målprisfordeling og bruk av eventuelt øvre tak. Videre må kunden vurdere hvilke elementer av tilleggspriser som skal aksepteres. Det er spesielt viktig å beslutte om administrasjon skal inngå i hver enkelt oppdragsavtale eller være et fast påslag. Hvis omfanget av oppdragsavtaler er stort, vil det siste være mest aktuelt fordi det da er et fast apparat som administrerer alle oppdrag og leveranser.
Normalt deles både overskridelser og underskridelser av målpris med 50 % av timepris avhengig av vurdering av usikkerheten. Øvre tak benyttes når leverandøren har god kjennskap til programvaren og således har spesielle forutsetninger for å kunne gi presise estimater. I slike tilfeller kan det settes et øvre tak, typisk etter 30 % overskridelse, kunne medføre ytterligere reduksjon av timepris, til for eksempel 30 %.
Størrelsen på påslagene for arbeid under godkjenningsprøven, for versjonshåndtering og konfigurasjonsstyring og til slutt for administrasjon, bør være en konkurransefaktor mellom leverandørene på samme måte som for timepriser. De fleste leverandører vil besitte erfaringstall som vil bidra til at påslagene blir lagt på et realistisk nivå.
Nedenfor er de ulike priselementene illustrert i en tabell:
Elementer | Timer og omregning til NOK | Beløp eks. mva. | Eventuelt inkl. mva. |
1. Estimat for arbeidet etter tilbud og frem til og med systemtest | |||
2. Eventuelt tillegg for arbeid med utdypende løsningsspesifikasjon | |||
3. Ved målpris skal risikopåslag synliggjøres | |||
4. Fast påslag i % for arbeid som må påregnes i godkjenningsprøven | |||
5. Faktisk timeforbruk oppad begrenset til angitt % av den definerte pris som fremgår av oppdragsavtalen | |||
6. Tilleggspris for administrasjon, enten et fast påslag på angitt % av den definerte pris som fremgår av oppdragsavtalen |
De tre første punktene er de som fast inngår i oppdragsavtalens pris, hvorav den tredje kun ved målpris.
Ved målpris skal under-/overskridelse fordeles mellom partene ved avregning. Her inngår også fratrekk for eventuelt arbeid utført av kundens personale.
I enkelte tilfeller vil det være nødvendig med en utdypende løsningsspesifikasjon (punkt 2 i tabellen ovenfor). Det må da beskrives hvordan prising av løsningsspesifikasjonsarbeid skal foretas, som alternativ til Konsulentbistand, herunder dekning av medgått tid dersom det ikke inngås en Oppdragsavtale. Alternativene til separat konsulentbistand er at arbeidet med løsningsspesifikasjon inngår i estimatet, enten basert på et anslag eller faktisk medgått tid.
Det må videre avtales om alt er fakturerbar tid, dersom arbeidet ikke resulterer i en oppdragsavtale.
Øvrige priselementer:
- Timepris for kundens merarbeid skal også angis.
- Det må videre 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.
- Til slutt må avbestillingsvederlag på en prosentsats av avtalt pris eller gjenstående del av dette, fremgå. Typisk avbestillingsvederlag vil være 4-6 %.
8 Vedlegg
Mal for oppdragsavtaler og oppdragslogg er vedlagt som bilag 5 og 6, men partene kan bli enige om å bruke andre maler dersom disse er dekkende.