Juridiske fallgruver for IT avtaler - Noen eksempler

(Skrevet 04.05.2001. Sist oppdatert 04.05.2002 )

Ved etablering og drift av netthandelsvirksomhet er det behov for å inngå ulike avtaler som både sikrer forutberegnelighet og samtidig fleksibilitet. I første rekke er det behov for avtaler som legger til rette for etablering og drift av infrastrukturen som nettvirksomheten er avhengig av. I tillegg kommer avtaler med underleverandører og forhandlere etc, som ikke omtales her.

Artikkelen gir en kortfattet og forenklet oversikt over et utvalg sentrale kontraktsrettslige emner, beregnet for ikke jurister. Kompleksiteten på området tilsier at artikkelen ikke kan erstatte kvalifisert juridisk gjennomgang av ulike spørsmål knyttet til en konkret leveranse. Artikkel søker i stedet å gi en liten oversikt over utvalgte temaer som ofte går igjen og som kan være egnet til øke bevisstheten om disse og tilhørende spørsmål. Som tilhørende spørsmål bør en særlig være klar over rettslige rammebetingelser i form av lovgivnig og vedtatte EU direktiver, som normalt vil ha betydning for utformingen av infrastrukturen og selve nettstedet. Disse spørsmål omtales ikke her, hvor fokus er satt på kontraktuelle emner.

En av suksessfaktorene for en vellykket IT anskaffelse eller IT prosjekt er en vel gjennomarbeidet avtale og overordnet kjennskap til de vanligste rettslige fallgruvene.

Ved inngåelse av avtaler som gjelder infrastrukturen er det erfaringsmessig fire rettslige hovedforhold man ofte bommer på:

• Valg av hensiktsmessig avtaletype
• Mangel på vel gjennomarbeidede vedlegg til avtalen, inkludert en forsvarlig kravspesifikasjon, hvor alle vedleggene er koordinert med avtalens juridiske bestemmelser og bakgrunnsretten
• Forståelsen av den viktige rettslige forskjellen mellom å beskrive leveransen komponentbasert eller funksjonsbasert
• Regulering av tilgang til kildekode, der det er behov for dette

Normalt er det behov for ulike avtaler for forskjellige typer leveranser. Som eksempler kan nevnes:

• avtale for tilknytning til Internett (ISP)
• avtale med en host eller web hotel hvis data skal lagres eksternt.
• avtaler for anskaffelse av standard hardware og/eller software,
• alternativt - systemutviklingsavtaler, hvis systemet skal baseres på nyutvikling eller større tilpasninger eller integrasjonsarbeid.
• avtaler for vedlikehold og support ytelser
• escrow avtaler for tilgang til kildekode
• etc

En klassisk fallgruve ved valg av avtale er bruk av en regulær avtale for anskaffelse av standard hardware og software på et prosjekt som reelt dreier seg om systemutvikling eller utførelse av større tilpasninger eller integrasjonsarbeid. Systemutvikling forutsetter helt andre bestemmelser i selve avtaledokumentet, samt spesifikasjoner i vedleggene, for eksempel knyttet til beskrivelsen av hva som skal leveres, fremdriften, arbeidsform, test metodikk (enhetstest, systemtest, integrasjonstest, leveranseprøver), herunder regulering av immaterielle rettigheter og tilgang til kildekode.

De nærmere juridiske detaljene ved ulike IT - avtaler utgjør et for stort felt til at det kan behandles her.

Det generelle aspektet ved slike avtaler – som ikke kan sies for ofte - går på at man grundig vurderer om man har tatt utgangspunkt i riktig avtaleform og tilpasset denne til det konkrete prosjektet. Standardavtaler kan være vel og bra som et utgangspunkt, men erfaringsmessig har ethvert prosjekt visse særtrekk som krever større eller mindre tilpasninger.

Det andre minefeltet man gjerne snubler i er kravspesifikasjonen til avtalene, gjerne inntatt som vedlegg til avtalen. Disse vedleggene inneholder normalt de juridisk sett viktigste forhold i avtalen. Her beskrives mer eller mindre uttømmende avhengig av kompleksiteten og størrelsen på leveransen bla:

• generelle og konkrete angivelser av formålet med leveransen
• hva som skal leveres (for større leveranser ofte i separate vedlegg med angivelse av programvare og utstyr)
• hvilken dokumentasjon og opplæring som medfølger eller kan kjøpes i tillegg
• hvorledes leveransen skal implementeres, herunder angivelse av prosjektteamet og ansvarsorganiseringen (oftest ved komplekse større prosjekter)
• Fremdrifts og tidsplaner (helst med angivelse av ansvar og avhengigheter mellom aktivitetene som skal utføres)
• Angivelse av de ulike testene som skal utføres (trinnvis utvikling), utarbeidelse av testprosedyrer og kriterier, samt godkjennelsesmekanismer for de tester som skal ha slike.
• Priser og betalingsbetingelser
• Opsjoner på eventuelle senere tilleggskjøp

Avhengig av kompleksitet, størrelse på leveransen og hensiktsmessighetsvurderinger, vil ovennevnte beskrivelser kunne inkluderes i ett og samme vedlegg eller inntas i separate vedlegg for hvert emne.

Til tross for viktigheten av grundighet og analyse, nedprioriteres dessverre disse vedleggene i en del situasjoner eller blir mindre godt koordinert med de juridiske betingelsene eller blir utarbeidet og gjennomgått av personer uten tilstrekkelig kompetanse til å se de spesielle sidene av samspillet mellom juridiske og faktiske forhold innen IT.

Det er viktig at man har et bevisst forhold til den viktige rettslig forskjellen mellom å spesifisere leveransen funksjonelt eller komponentbasert. De fleste som anskaffer et IT system, gjør dette for at systemet skal utføre visse funksjoner. Til tross for dette ser man gjerne at kravspesifikasjonen består av en mer eller mindre gjennomtenkt opplisting av hardware, software og nettverkskomponenter. Forskjellen mellom en funksjonell og komponentbasert kravspesifikasjon, kan illustreres med et relativt banalt eksempel fra den "fysiske" verden:

En bedrift skal anskaffe store skreddersydde feiemaskiner til sine industrilokaler. Bedriftens kompetente innkjøpsavdeling bruker lang tid på å sette opp en meget detaljert spesifikasjon hvor de beskriver kravene til maskinens bestanddeler og utforming. Maskinene blir levert, men feier ikke slik kunden hadde forutsatt i sine interne vurderinger.

I en slik situasjon vil leverandøren kanskje kunne hevdes å være forpliktet til å levere en forsvarlig sammensatt utgave av de bestanddeler som er opplistet – en såkalt komponentbasert kravspesifikasjon. Men siden poenget med anskaffelsen neppe er å få levert en lang liste deler pent sammenskrudd, men i stedet å få en maskin som kan feie opp et visst antall gram støv per tidsenhet, burde kontrakten også inneholde bestemmelser som forplikter leverandøren til dette (en funksjonsorientert objektiv målbar kravspesifikasjon).

Overført til IT anskaffelser ser man ofte uheldige avtaler basert på den samme tankegangen, hvor man spekker opp og ned i mente hvilke komponenter systemet skal bestå av, men i forbausende liten grad fokuserer på forretningskritiske objektive målbare funksjoner for hva systemet skal kunne gjøre eller yte.

Typisk knytter dette seg til angivelse av:

• oppetid (med flere undervilkår, se eksempelet nedenfor)
• responstid (med flere undervilkår)
• kapasitet (antall samtidige brukere, bruk av flere applikasjoner, transaksjonslast, lagringvolum)
• graden av kompatibilitet med eksisterende og fremtidige systemer
• oppgraderingsmuligheter
• utbygningsmuligheter.
• Drift og vedlikeholdsutgifter

Det mest hensiktsmessige kan ofte være å kombinere funksjonelle og komponentbaserte krav til løsningen, men slik at de funksjonelle kravene går foran ved motstrid.

En annen juridisk tommelfingerregel kan være at man søker å ivareta de forretningskritiske faktorene man er avhengig av i alle IT-avtaler (sikre ryggdekning eller såkalt "back to back" koordinering). Det fremstår som mindre godt koordinert dersom din systemleverandør har lovet et system med 98,8 prosent oppetid fra kl. 08.00 til 19.00 syv dager i uken 365 dager i året, når leverandøren av internett tilknytningen ligger betydelig lavere, slik at netthandelsvirksomheten din taper kunder og anseelse fordi "inngangsdøren" bokstavelig er stengt grunnet mye nedetid.

Nedenfor behandles oppetid som et eksempel. Her svikter det mange ganger både i avtalene med de som står for systemutviklingen og ISP som står for internett tilknytningen, gjerne ved at kravet er angitt med skjønnsmessige adjektiver.

Hva er meget høy oppetid?

Oppetid bør angis i prosent, men da er man bare ett skritt på veien. I tillegg bør det angis hva som er målevinduet. Skal oppetidsprosenten måles mellom 08.00 og 18.00 eller baserer målevinduet seg på 24 timer, syv dager i uken, 365 dager i året. Sistnevnte målevindu gir helt andre prosenttall.

Dernest - hva er målestedet for oppetid, som gjerne illustrerer i hvilken grad man har tenkt i gjennom og for eksempel bærer risikoen for at linjene til ISP`en faller ut. Er det angitt hvilke hardware og software forutsetninger måletallene baserer seg på? Hva om disse endres? Er lasten på systemet beskrevet, både hva gjelder transaksjonsvolum (gjerne knyttet til last, samtidige brukere eller en kombinasjon), hvilke programmer som skal opereres samtidig, herunder lagringsvolum.

Det er en kjent sak at oppetiden gjerne blir dårligere når man øker antall samtidige brukere, antall programmer eller transaksjonsvolumet generelt.

Forutsatt at man har et bevisst forhold til disse og andre underspørsmål, er det også viktig å angi hva som skal skje ved brudd på oppetidsprosenten, ut over krav til feilretting og utbedring

Her kan man gjerne angi en tabell som fastsetter et prosentuelt avslag som stiger med økt nedetid og at man gis rett til å iverksette ytterligere sanksjoner ved nedetid over et visst minimumsnivå.

I en del situasjoner er man avhengig av tilgang til kildekode. For å sikre denne tilgangen bør man i visse situasjoner inngå en egen kildekodedeponeringsavtale, også kalt escrow avtale. Typisk slik at man kan få tilgang til koden fra en uavhengig tredjemann som har oppbevart en oppdatert kopi av denne og er forpliktet til å utlevere denne på nærmere objektivt klare betingelser, for eksempel dersom leverandøren legger ned sin virksomhet, går konkurs etc.

En annen viktig praktisk og juridisk tommelfingerregel kan være å tegne opp all hardware, software og nettverkskomponenter og aktører du er avhengig av for å kunne oppfylle dine egne leveringsforpliktelser til dine kunder. Spørsmålet er hvilke av disse faktorene du har juridisk eller faktisk kontroll over. Der dette mangler, bør du vurdere å skaffe deg kontroll, fraskrive deg ansvar i avtaler dersom dette er juridisk og forretningsmessig mulig eller ta et bevisst forretningsmessig valg ved å akseptere risikoen som ligger i manglende kontroll

Slike tegneøvelser har gjerne avdekket viktige forhold som mangler god rettslig regulering og/eller operativ og driftsmessig håndtering.

Avslutningsvis knyttes det noen kortfattede kommentarer til de vanligste fasene i et systemutviklingsprosjekt illustrert på denne pilen.

Det kan ofte være inngått avtale før man utarbeider kravspesifikasjon, da gjerne som en forprosjektavtale eller en intensjonsavtale.

Utarbeidelsen av kravspesifikasjon leder så opp til avtaleinngåelse og deretter følger en utviklingsfase. Utviklingsfasen styres av forsvarlige utarbeidende milepælsplaner med tilhørende utviklings- og testmetodikk som inngår som vedlegg til avtalen og som løpende bør oppdateres etter behov. Her syndes det ofte stort. Som eksempler forbigås i alt for stor grad definering av avhengigheter mellom aktiviteter, herunder underestimeres ressursinnsatsen og dominoeffekter. Videre svikter gjerne strukturell stegvis fremdrift med utviklings- og testmetodikk basert på for eksempel enhetstest, systemtest, systemintegrasjonstest og ulike pilot tester før godkjennelsesperioden begynner. Enten har man avtalt dette utilstrekkelig eller så har man avtalt det, men lagt kontrakten som skal fungere som et arbeidsverktøy i skuffen. Denne skuffen åpnes dessverre først når prosjektet har havnet i grøfta – og da er det gjerne for sent.

I godkjennelsesperioden ser man at en del ikke er klar over "bordet fanger" reglene som blant annet finnes i en del standardavtaler og som tilsier at manglende formelt korrekt tilbakemelding i løpet av og ved utløpet av godkjennelsesperioden medfører passiv aksept av leveransen.

Etter at leveransen er akseptert enten aktivt eller passivt starter gjerne garantiperioden hvoretter leverandøren har nærmere utvidede forpliktelser til å rette ulike feil og mangler. Dernest påbegynner vedlikeholds- og supportperioden som gjerne er undergitt en separat avtale eller vedlegg.