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:

Ensidig endringsrett

Next page:
Previous page: Behovet for å foreta endringer Next page: Endringsavtaler

Et viktig spørsmål er om en part, i praksis kunden, skal ha rett til ensidig å gjøre endringer. Det er mye som taler for å gi kunden en slik rett. Det er kunden som skal ta det leverte system i bruk, og han bør kunne ta hensyn til endrede forhold og til erfaringer som vinnes i perioden mellom kontraktsinngåelse og endelig levering. SSA K95 pkt. 4.5 og 4.6 gir i realiteten kunden en avgrenset endringsrett. Disse er formulert som en plikt for leverandøren til å gi tilbud på nytt utstyr, og på nye programversjoner og nye programmer av interesse for kunden. Plikt til å gi tilbud som kunden så kan velge å akseptere, betyr i praksis at kontrakten gir rett til nyere utstyr og programmer. Man kunne derfor like godt ha formulert dette som en rett til å kreve utskiftning av enheter som omfattes av leveransen. Men ved å velge denne kontraktsteknikken betyr det at prisen må klargjøres før det avgjøres om endring skal foretas. Dersom man har spesifisert enhetspriser i kontrakten, vil det være uproblematisk å fastsette verdien av det som utgår av leveransen.

Det går en grense for hvor sent i prosessen man kan akseptere selv så enkle endringer som å skifte ut standardkomponenter. Hvis leverandøren allerede har bestilt enhetene inn til eget lager, og denne bestillingen ikke kan endres, er det lite rimelig å kreve at leverandøren skal ta de gamle modeller til lager og levere nytt til kunden.

I entrepriseforhold har byggherren (oppdragsgiver) vanligvis en rett til å pålegge entreprenøren endringer, se NS 3430 pkt. 28.1. Også ved leveranser til oljeindustrien er dette vanlig, se NF 92 art. 12-16.(110) Ved IT-leveranser har en slik omfattende ensidig endringsrett til nå ikke vært vanlig. Men de nye standardavtalene for systemutvikling fra Statskonsult og KDL har begge et endringsregime som er adoptert fra petroleums- og entreprisekontrakter. Begge kontraktene gir kunden rett til å pålegge endringer innenfor visse rammer. SSA U97(utk) pkt. 9.1 gir rett til å pålegge endringer som samlet utgjør opptil 15% av kontraktssummen (som tilsvarer NS 3430 pkt. 28.1 og NS 3431 pkt. 33.1), mens KDL U97 pkt. 6.1 forutsetter at grensen fastsettes i bilag. Til sammenligning setter NF 92 pkt. 12.1 ingen slike grenser utover at kunden (selskapet) ikke kan «foreskrive endringsarbeider som samlet sett går ut over hva partene med rimelighet kunne regne med da Kontrakten ble inngått».

NF 92, har kunden prosjekteringsrisikoen. Ved systemutvikling vil i alle fall en betydelig del av prosjekteringsrisikoen ligge hos leverandøren, hvilket etter min mening også tilsier at leverandøren bør ha mer å si når det gjelder endringer. Det er heller ikke vanskelig å finne eksempler på at tilsynelatende enkle endringer har vist seg svært vanskelig å foreta, fordi de forutsetter dyptgripende endringer i systemet.

Som eksempel er det fristende å peke på den bedrøvelige minnegrensen på 640kb i MS-DOS, som de fleste PC brukere har slitt med siden MS-DOS ble introdusert i PC'ens barndom. Allerede den gang var Bill Gates tydeligvis flinkere til å selge begrensede produkter enn til å få fram den beste teknologien. Han kunne ikke forestille seg at noen brukere noen gang ville ha behov for mer enn 640kb minne på en PC, og man la visse systemfunksjoner i minneområdet mellom 640 og 1024kb. Dermed la man et «tak» på tilgjengelig primærminne. Siden den gang har det vært gjort mye for å omgå og kamuflere hindringen, men også dagens Windows95 lider under denne begrensningen. I MS-DOS' konkurrent i PC alderens begynnelse, CP/M-86, lå disse systemfunksjonene i et annet minneområde, slik at man unngikk «640k taket». Så hvis ikke MS-DOS hadde vunnet markedet, ville vi sluppet mange problemer og det ville ikke ha vært noe stort marked for de utallige programmer som gjennom årene er laget for å omgå MS-DOS' minnebegrensning. Systemer som Unix, OS/2 og Windows NT har en annen og bedre minnehåndtering, slik at disse ikke lider under den samme begrensning som MS-DOS baserte systemer. Endringer som i prinsippet er enkle, er helt umulige for programutviklere på grunn av begrensninger i systemets kjerne. Og tilsynelatende enkle endringskrav fra brukere vil være umulig å etterkomme dersom de forutsetter endringer i slike basisfunksjoner.

Systemet i begge de nye standardavtalene er at kunden kan sende en endringsordre, se SSA U97(utk) pkt. 9.3 og KDL U97 pkt. 6.3. Leverandøren skal så utstede et endringsoverslag i henhold til SSA U97(utk) pkt. 9.2 eller KDL U97 pkt. 6.2.

Både Statskonsult og KDL har holdt seg så tett opptil sitt forbilde NF 92 at de også har behold den etter min mening noe uheldige systematikk i denne kontrakten: Bestemmelsen om leverandørens svar på endringsordre kommer før bestemmelsene om utstedelse av endringsordre. NS 3430 pkt. 28 og NS 3431 pkt. 33 er etter min mening bedre redigert på dette punktet.


Kontraktene har noe avvikende ordlyd når det gjelder krav til endringsoverslag fra leverandøren, hvilket bl.a. reflekterer noe ulik terminologi på andre punkter i kontrakten. Men realiteten er stort sett de samme både i SSA U97(utk) pkt. 9.2 og KDL U97 pkt. 6.2.2. Endringsoverslaget skal inneholde:

* Beskrivelse av endringen.

* Beskrivelse av arbeid som må utføres som følge av endringen (ressurser, tidsforbruk m.m.)

* Virkningen for spesifikasjon av ytelsen.

* Virkningen for teknisk plattform.

* Virkningen for kontraktsprisen med beregningsgrunnlag.

* Virkningen for fremdriftsplanen.

* Endrede krav til kundens medvirkning.

* Endringer i testplaner og testkriterier.

* Arbeid og kostnad med å utarbeide endringsoverslag.

Kostnadene forbundet med å utarbeide endringsoverslag skal etter begge kontrakter betales av kunden.

Hvis leverandøren mener at endringene ikke kan gjennomføres, eller at de innebærer en meget stor risiko, må dette i såfall fremgå av endringsoverslaget.

Dersom det er tvist om konsekvensene av en endring, har begge kontrakter visse mekanismer for å håndtere dette. Ved tvist om betaling forutsettes at kunden betaler et foreløpig vederlag, og at leverandøren må reise søksmål innen 6 måneder, se SSA U97(utk) pkt. 9.5 og KDL U97 pkt. 6.5.1. KDL U97 pkt. 6.5.2 regulerer tvist om endringsordrens virkning på fremdriften. KDL U97(utk) har ikke en tilsvarende bestemmelse.

Systemet med endringsordrer forutsetter at alle endringer skal skje i denne formen. I praksis vil det ofte gjøres en rekke mindre endringer og justeringer underveis i et utviklingsprosjekt. Hvis det ikke er utstedt endringsordre må slike mindre endringer gjennomføres innenfor avtalte tids- og kostnadsrammer, og uten at prosjektet påvirkes på andre måter. Hvis leverandøren mener at slike endringer er av et omfang som tilsier endringer i fremdrift, pris m.m., må leverandøren kreve at kunden utsteder endringsordre. Hvis kunden er uenig i at dette skal regnes som endring, skal det utstedes omtvistet endringsordre, se SSA U97(utk) pkt. 9.7 og KDL U97 pkt. 6.6. Begge kontrakter forutsetter at tvist om endring i første omgang løses ved en oppmannsavgjørelse (i KDL U97 pkt. 6.6.3 kalt ekspertavgjørelse). Dersom en av partene ikke godtar oppmannsavgjørelsen, kan tvisten bringes videre for avgjørelse etter kontraktens vanlige mekanismer for tvisteløsning.

Når det er avtalt prosedyrer for endringer og tilleggsarbeider, må disse følges for at leverandøren skal kunne kreve betaling og/eller fristforlengelse, se ND 1989 s. 356 Gulating.

Selv enkle endringer, f.eks. i form av nye programversjoner, kan få konsekvenser for øvrige deler av leveransen. Det er ikke uvanlig at nye programversjoner krever mer maskinressurser enn tidligere versjoner. Nye versjoner vil da ikke fungere tilfredsstillende hvis man ikke samtidig oppgraderer maskinene. Leverandøren er den som er nærmest til å vite slikt. Dersom leverandøren pålegges plikt til å gi tilbud, bør man kreve at tilbudet inneholder opplysninger om eventuelle endringer i maskinkrav. Hvis kunden gis rett til å kreve oppgraderinger, bør leverandøren pålegges å varsle om eventuelle økte maskinkrav, slik leverandøren er pålagt etter SSA K95.

Endringer som bare innebærer reduksjon i forhold til det som opprinnelig ble bestilt, er i denne sammenhengen mindre problematisk, forutsatt at de elementer som utgår ikke er en forutsetning for at andre deler av ytelsen skal kunne nyttes som forutsatt. Dette kan ses på som en avbestilling, og kunden kan innrømmes en slik rett mot å betale erstatning etter samme prinsipper som ved total avbestilling, se nærmere kapittel 15.

Også leverandøren kan i noen grad være interessert i å foreta endringer, i første rekke ved å levere nyere programversjoner enn de som er spesifisert i kontrakten. Hvis det ikke krever økte maskinressurser, vil kunden vanligvis være interessert i siste versjon av programmene. Men han kan ha sine grunner til ikke å gjøre det. For det første har det betydning å ha samme programversjon alle steder hvor programmet er installert, også på tidligere installerte systemer som ikke omfattes av den aktuelle leveransen. Kunden kan derfor være interessert i å utsette oppgradering til det kan gjøres under ett. For det annet kan kunden ønske at nye programmer skal fungere sammen med andre programmer som kunden har, og det er ikke gitt at nye programmer fungerer like godt som de gamle. Videre er det ikke sjelden at nye versjoner av programmer som innebærer omfattende oppgraderinger, inneholder til dels betydelige feil. Kunden kan derfor være interessert i å vente med å ta i bruk nye versjoner til de har blitt grundig testet. Enkelte brukere er ?? ikke uten grunn ?? skeptiske til å ta i bruk versjon x.0 av et program. Endelig er det en del brukere som på grunn av kostnadene velger ikke å oppgradere hver gang det kommer en ny versjon. Etter min mening bør leverandøren av disse grunner som hovedregel ikke gis rett til ensidig å foreta endringer.

Til nå har det vært vanlig å endre versjonsnummeret med hele tall ved betydelige oppgraderinger, mens man endrer første desimal ved mindre oppgraderinger. Andre desimal, eventuelt endret bokstav etter første desimal, betegner gjerne nye versjoner som ikke inneholder nye funksjoner, bare retting av feil. Men versjonsnummer velges også ut fra markedsføringshensyn, så praksis er på ingen måte konsekvent.

Noen bøker om IT-kontrakter


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

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

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


Previous page: Previous page: Behovet for å foreta endringerNext page: Endringsavtaler Next page:

Next page: Endringsavtaler Next page:

Previous page: Previous page: Behovet for å foreta endringer