Bing Hodneland logo

Fra 1. august 2012 vil jeg være advokat på heltid som partner i Bing Hodneland.



Nye bøker


Mer >>
Flere nye bøker

Gå til "bokhandelen"

Geocaching i Norge
Amazon US
In Association with Amazon.co.uk


Previous page:

Noen særtrekk ved IT-kontrakter

Next page:
Previous page: Hovedtyper av kontrakter Next page: Rettskildesituasjonen

Ethvert kontraktsområde har sine særmerker. Disse kan dels følge av kontraktstypens egenart, dels av at praksis i ulike bransjer kan ha utviklet seg i ulike retninger. Men samtidig er det betydelige fellestrekk mellom de ulike kontrakter. Den alminnelige kontraktsrett utledes i stor utstrekning ved generaliseringer fra det som er praksis innenfor spesiell kontraktsrett, mens spesiell kontraktsrett utvikles med den alminnelige kontraktsrett som bakgrunn.

Det har vært en etter min mening for sterkt tendens til å betone det spesielle ved IT-kontraktene. Så lenge dette bare får betydning for hvilke problemstillinger man ønsker å behandle, betyr det ikke så mye. Men når det også får den konsekvens at man begrenser sitt kildemateriale til kontrakter, rettspraksis og teori som omhandler slike kontrakter, får det uheldige konsekvenser for resultatet. I den norske litteraturen på dette området har man i liten grad utnyttet materiale fra alminnelig kontraktsrett, kjøp, entreprise m.v. i drøftelser av IT-kontrakter, og noen ganger kan man få et inntrykk av at man har villet «finne opp hjulet på nytt». For tolkningen av en dagbotklausul har det f.eks. liten betydning om den gjelder bygging av oljeplattformer, levering av elektriske generatorer eller IT-leveranser. Også for andre kontraktsspørsmål er det mye å hente fra alminnelig kontraktsrett og fra andre rettsområder. Problemet med IT-kontrakter er heller at de har likhetspunkter med så mange forskjellig kontrakter og at de ikke lar se plassere i én av de tradisjonelle kontraktskategorier, og ikke at de er så ulike andre kontrakter.

Av forhold som særmerker IT-leveransene, kan nevnes:

IT-kontrakter vil ofte gjelde levering av varer og tjenester som har sentral betydning for organisering og drift av kundens. Et edb-system fremstår gjerne som «sentralnervesystem» i kundens organisasjon. Dette gjelder enten systemet brukes i administrasjonen eller det styrer produksjonsprosesser. Systemet skal integreres i en eksisterende organisasjon. En IT-anskaffelse kan som regel ikke isoleres som et selvstendig prosjekt adskilt fra den løpende virksomheten. Et nytt bygg eller en boreplattform kan være vel så komplisert og mye dyrere enn et IT-system, med disse kan avgrenses og isoleres fra kundens organisasjon og løpende drift. Kunden vil derfor være sårbar ved feil og mangler ved den leverte IT-ytelse.

Kundenes IT-kompetanse vil ofte være lav. Kunden skal ha løst en oppgave, og edb er et verktøy for å gjøre dette. Man får dermed et betydelig innslag av rådgivning, enten fra leverandør(er) eller fra selvstendige rådgivere. Etterhvert finner man både andre- og tredjegangskjøpere blant kundene. Men utviklingen går så fort at den som ikke har fulgt med hele tiden, vil være ganske uvitende om dagens systemløsninger selv om de har erfaring som brukere av eldre systemer.

Det vil ofte bli inngått avtaler om løsninger basert på nye og uprøvde løsninger. Dette får for det første betydning for risikovurderingen i forhold til forsinkelser og mangler. Men det får også betydning for leverandørens opplysnings- og lojalitetsplikt overfor kunden, ikke minst i de tilfeller hvor kunden selv mangler forutsetninger for å vurdere de løsninger som foreslås.

Ved utvikling av programvare møter en det problem at det er vanskelig å sette mål på den ytelse som skal leveres. Det er vanskelig nok å definere hvilket mål som skal nås, men enda vanskeligere å definere delmål. I et byggeprosjekt er det ikke så vanskelig å se når grunnmuren er ferdig, når taket er reist, osv. Ved utvikling av et dataprogram kan en lett konstatere at programmet ikke er ferdig, men det er vanskelig å konstatere hvor langt man egentlig er kommet i utviklingen. Man kan sammenligne med å skrive en tekst: Det er lett å se at man har et uferdig utkast, men ikke lett å avgjøre hvor mye som gjenstår før boken er ferdig. Og det er vanskelig å angi en milepæl gjennom en angivelse av hvor langt utviklet utkastet skal være på et gitt tidspunkt.

I et bok-prosjekt som det jeg nå holder på å avslutte, merkes dette godt. For ganske lenge siden trodde jeg at jeg skulle bli ferdig i neste uke. Og jeg har i det siste startet om morgenen med etter min mening berettiget håp om å bli ferdig i løpet av dagen, for så utpå natten å konstatere at det ble jeg ikke likevel. Dateringen på forordet har jeg måttet endre fra juni til juli, og klokken er blitt så mange at jeg nok ikke blir ferdig i dag heller. Men i morgen ......


Sammenligner man utviklingsavtaler med entreprisekontrakter, finner en også i IT-kontrakter består i kompliserte ytelser som alltid vil få et improvisasjonspreg.(13) Ved oppføring av bygg og anlegg er det alltid en risiko for at ytre forhold skaper komplikasjoner. Det vil typisk være grunnforhold på stedet og værforhold i byggeperioden. Slike forhold har ingen betydning for IT-prosjekter. Til gjengjeld vil IT-prosjekter svært ofte innebære at man i større eller mindre grad gir seg i kast med noe som ikke er gjort før, hvilket i seg selv innebærer risiko og gjør det vanskelig å beregne tidsforbruk. Man kan si at ytre forhold representerer en risiko ved entreprise, mens det mer er forhold i prosjektet som representerer risikoen ved IT-prosjekter. Videre vil leveringssituasjonen være en helt annen. Et forsinket eller mangelfullt bygg kan ikke enkelt fjernes fra byggeplassen, og det er lite praktisk for byggherren å erstatte det halvferdige bygget med et annet. Misligholdssanksjoner, og da særlig hevning, vil derfor måtte bli forskjellig.

Ved entreprise er det vanlig å skille mellom konstruksjon eller prosjektering, og utførelse. Konstruksjonen er resultatet av et intellektuelt arbeid, mens utførelse er fysisk arbeidsaktivitet.(14) Ved utvikling av programvare kan man ikke trekke et slikt skille. Her består utviklingen kun av prosjektering/konstruksjon, ferdigstillelse er bare spørsmål om detaljeringsgrad. Men i motsetning til den rene prosjekteringsavtale, så skal det leveres et ferdig sluttprodukt.

Levering av datamaskinprogrammer vil i stor grad innebære overdragelse av opphavsrettslige beføyelser. Det er på dette punkt IT-kontraktene rettslig sett skiller seg vesentlig fra de fleste andre kontrakter.

Endelig har det betydning at IT-markedet er ungt, og at det utvikler seg og endres meget raskt. Det er ikke mer enn ca 16 år siden IBM lanserte sin første personlige datamaskin, for 5 år siden var Internett knapt kjent utenfor akademiske miljøer, og for 3 år siden fantes det visstnok bare ca 50 web-tjenere i verden. Man skal ikke mange år tilbake før en edb-leveranse var ensbetydende med et stort, sentralt edb-system, og ingen hadde hørt om nettverksløsninger. Når man drøfter kontrakter for leveranser som strekker seg over noe tid, vil man nesten alltid sikte på et bevegelig mål. Men her beveger målet seg raskere enn på de fleste andre områder.

Det fremheves også i mange sammenhenger at i seg selv ganske ubetydelige feil kan få dramatiske konsekvenser.(15) Dette er imidlertid noe som gjelder alle leveranser av i seg selv små, men betydelige komponenter til store konstruksjoner og systemer. En av de dommer som er omtalt flere steder i denne boken, RG 1966 s. 443 Oslo (strekkfisk) illustrerer detter. En strekkfisk solgt for 22,50 kr røk, noe som forårsaket skader som leverandøren måtte erstatte med drøyt 7.500 kr.

En grunn til at IT-kontrakter har blitt fremhevet som noe spesielt og komplisert, synes også å være at det er spesielt og komplisert for mange av de personer som konfronteres med dem. Med edb har en komplisert teknologi gjort sitt inntog i administrativ virksomhet. For en som tidligere har vært vant til å anskaffe blyanter og papir, noen kontormøbler og skrivemaskiner, samt en og annen kopimaskin, vil IT-kontraktene virke både skremmende og kompliserte. For den som er vant til å håndtere kontrakter for anskaffelse av produksjonsutstyr til industrien, er kontraktene ikke mer kompliserte enn andre kontrakter man ellers må forholde seg til.

Noen bøker om IT-kontrakter


More >>
Kontrakter for utvikling av programvare
Boka tar for seg utviklingskontrakter for dataprogramvare.
RefNr: 9788202196912
Bestill fra:
Bokkilden

More >>
The Managers Guide to Understanding Commonly Used Contract Terms: Comm
RefNr: 0852977581
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
The Outsourcing Revolution: Why it Makes Sense to do it Right: Why It
The Outsourcing Revolution" features case studies detailing how specific companies planned, implemented, and are managing BPO. Results from surveys of more than 1,500 companies provide real data on what organizations around the world are doing and why, as well as what does and doesn't work.
RefNr: 0793192145
Bestill fra:
Amazon UK
Amazon US
Bokkilden

More >>
Outsourcing: The Legal Contract
Providing an introduction to outsourcing, this title identifies and discusses the main aspects which should be specified in the contract and indicates the factors which facilitate a successful outsourcing relationship.
RefNr: 1841523607
Bestill fra:
Amazon UK
Amazon US
Bokkilden

Gå hit for full oversikt over bøker om IT-kontrakter.


Previous page: Previous page: Hovedtyper av kontrakterNext page: Rettskildesituasjonen Next page:

Next page: Rettskildesituasjonen Next page:

Previous page: Previous page: Hovedtyper av kontrakter