<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="no" lang="no">
<head>
<title>Juridiske fallgruver for IT avtaler - Noen eksempler | Paragrafen.no</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<link rel="stylesheet/less" type="text/css" href="/less/style.less" />
<script src="/less/less.js" type="text/javascript"></script>
<script src="/js/bootstrap.min.js" type="text/javascript"></script>
<script src="/js/bootstrap-dropdown.js" type="text/javascript"></script>
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-776802-7']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
<script type="text/javascript">
function skrivEpost(prefix, postfix, navn) {
if (navn == '') navn = prefix +'@'+ postfix;
document.writeln('<a href=mailto:'+prefix+'@'+postfix+'>'+navn+'</a>');
}
</script>
<script>
(function() {
var cx = '001609671656242173473:nvhaao8y8_8';
var gcse = document.createElement('script'); gcse.type = 'text/javascript'; gcse.async = true;
gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +
'//www.google.com/cse/cse.js?cx=' + cx;
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(gcse, s);
})();
</script>
<link rel="alternate" type="application/rss+xml" href="https://www.paragrafen.no/rss/paragrafen.xml" title="Paragrafen.no"/>
</head>
<body>
<div class="navbar">
<div class="navbar-inner">
<div class="pull-left"><a class="brand" href="/" style="padding-top:0;padding-bottom:0;"><img src="/paragrafen.gif" alt="Paragrafen.no" style="height:40px;" /></a>
</div>
<ul class="nav">
<li><a href="/innholdsliste/">Artikler</a></li>
<li><a href="/advokat/">Advokater</a></li>
<li><a href="/guide.php">JussGuiden</a></li>
<li><a href="/nytt.php">Nye lenker</a></li>
<li><a href="/nyhetsliste/">Nyhetsbrev</a></li>
</ul>
<div class="span3 search-box">
<gcse:searchbox-only></gcse:searchbox-only>
</div>
</div>
</div>
<div class="row-fluid">
<div class="tabbable tabs-left">
<ul class="nav nav-tabs">
<li><a href="/">Forsiden</a></li>
<li>
<a href="/?kat=2">Arbeid</a></li>
<li>
<a href="/?kat=6">Arv</a></li>
<li>
<a href="/?kat=7">Diverse</a></li>
<li>
<a href="/?kat=8">Eiendom</a></li>
<li>
<a href="/?kat=9">Familie</a></li>
<li>
<a href="/?kat=10">Gjeld</a></li>
<li class="active">
<a href="/?kat=11">It</a></li>
<li>
<a href="/?kat=12">Kontrakter</a></li>
<li>
<a href="/?kat=13">Mekling</a></li>
<li>
<a href="/?kat=14">Selskaper m.v</a></li>
<li>
<a href="/?kat=15">Skatt</a></li>
<li>
<a href="/?kat=16">Straff</a></li>
<li>
<a href="/?kat=17">Tvist</a></li>
<li>
<a href="/?kat=18">Ungdom</a></li>
<li>
<a href="/?kat=19">Økonomi</a></li>
</ul>
<div class="tab-content">
<ul class="breadcrumb">
<li><a href="/">Forsiden</a> <span class="divider">/</span></li>
<li><a href="/?kat=11">It</a> <span
class="divider">/</span></li>
<li class="active">Juridiske fallgruver for IT avtaler - Noen eksempler</li>
</ul>
<div class="row-fluid">
<article class="span9">
<h1>Juridiske fallgruver for IT avtaler - Noen eksempler</h1>
<p class="muted">(Skrevet 04.05.2001. Sist oppdatert 04.05.2002 )</p>
<b>En av suksessfaktorene for en vellykket IT anskaffelse eller IT prosjekt er en vel gjennomarbeidet avtale og overordnet kjennskap til de vanligste rettslige fallgruvene.</b>Artikkelen er levert av <a href="http://www.tkgl.no"target="blank"><b>Thommessen Krefting Greve Lund AS Advokatfirma</b></a><br>
<br>
<u><a href="#_Ref506090759"><b>Innledning</b></a></u><br>
<u><a href="#_Ref506090779"><b>Valg av riktig type avtale</b> – grunnmuren i leveransen</a></u><br>
<u><a href="#_Ref506090786"><b>Kravspesifikasjonen</b> – juridisk sett ofte det viktigste dokumentet</a></u><br>
<u><a href="#_Ref506090791"><b>Funksjonell versus komponentbasert</b> kravspesifikasjon</a></u><br>
<u><a href="#_Ref506090799"><b>Oppetid</b> – eksempel på ett av områdene med en rekke underspørsmål</a></u><br>
<u><a href="#_Ref506090803"><b>Kildekode</b> – er du avhengig av tilgang til denne?</a></u><br>
<u><a href="#_Ref506090849"><b>Avhengigheter og domino effekter</b> – tegn opp og analyser</a></u> <div style="float:left;width:336px;margin:10px 10px 10px 0px;">
<script type="text/javascript"><!--
google_ad_client = "pub-4783001812230745";
google_alternate_color = "FFFFFF";
google_ad_width = 336;
google_ad_height = 280;
google_ad_format = "336x280_as";
google_ad_type = "text_image";
//2006-11-29: Paragrafen - Midt i artikkel
google_ad_channel = "5541931428";
google_color_border = "FFFFFF";
google_color_bg = "FFFFFF";
google_color_link = "0000FF";
google_color_text = "000000";
google_color_url = "0000FF";
//--></script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div>
<br>
<u><a href="#_Ref506090849"><b>Systemutvikling</b> – kort om de ulike fasene</a></u><br>
<br>
<font size="3"><b><a name="_Ref506090759">1. Innledning</a></b></font>
<p>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. </p>
<p><i>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. </i></p>
<p>En av suksessfaktorene for en vellykket
IT anskaffelse eller IT prosjekt er en vel gjennomarbeidet avtale og overordnet
kjennskap til de vanligste rettslige fallgruvene.</p>
<p>Ved inngåelse av avtaler som gjelder
infrastrukturen er det erfaringsmessig fire rettslige hovedforhold man ofte
bommer på:
<ul>
<li>Valg av hensiktsmessig avtaletype
<li>Mangel på vel gjennomarbeidede vedlegg til avtalen, inkludert en forsvarlig kravspesifikasjon, hvor alle vedleggene er koordinert med avtalens juridiske bestemmelser og bakgrunnsretten
<li>Forståelsen av den viktige rettslige forskjellen mellom å beskrive leveransen komponentbasert eller funksjonsbasert
<li>Regulering av tilgang til kildekode, der det er behov for dette</ul>
<br>
<font size="3"><b><a name="_Ref506090779">1.1
Valg av
riktig type avtale – grunnmuren i leveransen</a></b></font>
<p>Normalt er det behov for ulike avtaler
for forskjellige typer leveranser. Som eksempler kan nevnes:</p>
<ul>
<li>avtale for tilknytning til Internett (ISP)
<li>avtale med en host eller web hotel hvis data skal lagres eksternt.
<li>avtaler for anskaffelse av standard hardware og/eller software,
<li>alternativt - systemutviklingsavtaler, hvis systemet skal baseres på nyutvikling eller større tilpasninger eller integrasjonsarbeid.
<li>avtaler for vedlikehold og support ytelser
<li>escrow avtaler for tilgang til kildekode
<li>etc
</ul>
<p>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.</p>
<p>De nærmere juridiske detaljene ved ulike
IT - avtaler utgjør et for stort felt til at det kan behandles her. </p>
<p>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.</p>
<font size="3"><b><a name="_Ref506090786">1.2
Kravspesifikasjonen
– juridisk sett ofte det viktigste dokumentet</a></b></font>
<p>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:</p>
<ul>
<li>generelle og konkrete angivelser av formålet med leveransen
<li>hva som skal leveres (for større leveranser ofte i separate vedlegg med angivelse av programvare og utstyr)
<li>
hvilken
dokumentasjon og opplæring som medfølger eller kan kjøpes i tillegg
<li>
hvorledes
leveransen skal implementeres, herunder angivelse av prosjektteamet og
ansvarsorganiseringen (oftest ved komplekse større prosjekter)
<li>
Fremdrifts
og tidsplaner (helst med angivelse av ansvar og avhengigheter mellom
aktivitetene som skal utføres)
<li>
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.
<li>
Priser og
betalingsbetingelser
<li>
Opsjoner på
eventuelle senere tilleggskjøp
</ul>
<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. </p>
<p> 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.</p>
<font size="3"><b><a name="_Ref506090791">1.3
Funksjonell
versus komponentbasert kravspesifikasjon</a></b></font>
<p>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:</p>
<p><i>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></p>
<p>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). </p>
<p>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. </p>
<p>Typisk knytter dette seg til angivelse
av:
<ul>
<li>
oppetid
(med flere undervilkår, se eksempelet nedenfor)
<li>
responstid
(med flere undervilkår)
<li>
kapasitet
(antall samtidige brukere, bruk av flere applikasjoner, transaksjonslast,
lagringvolum)
<li>
graden av
kompatibilitet med eksisterende og fremtidige systemer
<li>
oppgraderingsmuligheter
<li>
utbygningsmuligheter.
<li>
Drift og
vedlikeholdsutgifter
</ul>
<p>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.</p>
<p>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.</p>
<font size="3"><b><a name="_Ref506090799">1.4
Oppetid –
eksempel på ett av områdene med en rekke underspørsmål</a></b></font>
<p>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. </p>
<p>Hva er
meget høy oppetid? </p>
<p>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. </p>