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:

I hvilken grad kan ytelsen spesifiseres på forhånd?

Next page:
Previous page: Innledning Next page: Resultat- og omsorgsforpliktelse

Det har vært satt spørsmålstegn ved den utstrakte bruken av kravspesifikasjon ved IT-leveranser. Det er ikke lett å spesifisere det som skal leveres på forhånd. Kunden har mer eller mindre presise oppfatninger av hvilke oppgaver han ønsker løst, men ikke om hvordan oppgavene konkret skal løses. Leverandøren har på sin side en teknologi som forhåpentligvis kan nyttes til å løse disse oppgavene. Leverandøren vil så måtte foreslå en løsning ut fra kundens beskrivelse, kunnskap om egne produkter, og den kompetanse de har på dette anvendelsesområdet. For å kunne utarbeide en god spesifikasjon må man ha gode kunnskaper både om de oppgaver som skal løses og om den teknologi som man vil anvende for løsningen. Det er sjelden man har tilstrekkelige kunnskaper på alle områder når spesifikasjonen utarbeides.

I en spesifikasjon kan man angi hvilke oppgaver som skal løses. Men man kan velge ulike teknologiske plattformer for å etablere en løsning. De ulike plattformer har sine styrker og sine begrensninger, slik at valg av plattform vil virke styrende på den endelige løsningen. En for rigid spesifikasjon vil innebære at kunden på forhånd må treffe valg som han har dårlige forutsetninger for, og valget vil kunne utelukke en del leverandører.

I tillegg kommer at utviklingen i markedet går raskt, særlig når det gjelder maskinvare. Det kommer stadig nye modeller som er raskere og har større kapasitet, samtidig som de blir billigere. Det har vært sagt at uansett hvilken maskin man velger og når man velger den, må man regne med at om 3 måneder har det kommet nye maskiner som man heller ville ha valgt. Hvis det har gått mer enn disse tre månedene fra man startet med spesifikasjonen til man faktisk kan begynne å levere, må man regne med at kunden kan være interessert i at han får de nye maskinene i stedet for de som det opprinnelige tilbudet er basert på. For programvare går ikke utviklingen like fort, men tendensen er den sammen.

På den annen side endres brukernes krav og forventninger i takt med utviklingen. Det som var «drømmemaskinen» for 10 år siden, kan man i dag få på loppemarked. Det har vært sagt at uansett hvor mye prisene synker, så koster den PC'en man har mest lyst på til enhver tid ca. 40.000 kr.

Gjennom avklaringsrunder og forhandlinger vil man kunne få presisert, utdypet og justert spesifikasjonene. Så lenge dette skjer før det inngås noen endelig avtale, skaper det ikke noen kontraktsrettslige problemer. Men det innebærer at en streng anbudsprosedyre, slik man har f.eks. i entreprise, se foran i avsnitt 3.1, ikke er egnet for slike leveranser. Læringsprosessen fortsetter også etter at kontrakt er inngått og spesifikasjonen er «låst».

WTO og E?S-reglene for offentlige anskaffelser forutsetter at det i utstrakt grad brukes anbud. Men anbudsmodellen forutsetter at har en ferdig spesifikasjon når skal innhente anbud. For IT-prosjekter vil det ofte ikke være tilfelle, og heller ikke alltid den beste løsningen. Forskjellige leverandører kan presentere ulike løsningskonsepter, og vurderingen kan like mye gå på hva som synes å være den beste løsningen som på pris m.m. Riktignok er det mulig å formulere ganske åpne anbud, legge vekt på andre ting enn pris, og å åpne for åpne anbud.(63) Men man tvinges her inn i en anskaffelsesmodell som ofte er lite egnet for den aktuelle anskaffelse.

I praksis kan man lett bli stilt overfor valget mellom å følge den opprinnelige spesifikasjonen og få en løsning som ingen av partene ønsker, eller å levere noe annet enn det man opprinnelig forpliktet seg til i kontrakten. Hvis man ikke følger den oppsatte spesifikasjonen, risikerer man problemer. Leverandøren har ikke levert det som fremgår av kontrakten, hvilket i utgangspunktet vil si at leveransen er mangelfull. Nå kan det hende at partene med åpne øyne har fraveket spesifikasjonen, ganske enkelt fordi man har funnet ut at denne ikke ville ha gitt en tilfredsstillende løsning. Men hvis kunden da ikke vil godta den løsning som er levert, eller ikke vil betale leverandørens tilleggsregninger, da får man lett problemer. Ved en konflikt vil man, i mangel av annet, ta utgangspunkt i kravspesifikasjonen.

Fra andre typer av leveranser er det ikke ukjent at man inngår avtaler og starter arbeidet før detaljprosjekteringen er ferdig.(64) Kostnadene vil ofte bli for store om man venter. Man vil få en forsinket oppstart, og man får store kapitalkostnader under prosjekteringen som man ikke kan begynne å dekke inn før etter at systemet er ferdig. Og man risikerer å få en løsning som er foreldet før den er tatt i bruk. Men hvis man velger å gå inn på denne type av avtaler, må man finne fram til rutiner for å håndtere de beslutninger som må treffes og de valg som må foretas underveis i prosessen.

Dette betyr ikke at man ikke skal sette opp kravspesifikasjon og eventuelt løsningsspesifikasjon. Man må på en eller annen måte definere oppdraget. Men man sikter mot et bevegelig mål, og må være forberedt på at spesifikasjonen bare er et utgangspunkt for en utviklingsprosess, og at resultatet ikke kommer til å være fullt ut i samsvar med de opprinnelige spesifikasjoner. Jo mer komplisert leveranse, og jo lenger varighet prosjektet har, desto mer avvik må man regne med underveis i prosessen. Utfordringen blir å håndtere denne situasjonen i kontrakten. Hvordan man kan håndtere slike endringer drøftes nærmere i kapittel 14.

Mange mener at såkalt inkrementell utvikling eller prototyping er en bedre utviklingsmodell. Men fortsatt vil det nødvendig med en spesifikasjon. Partene kan ikke starte et utviklingsprosjekt uten noen angivelse av hva oppdraget skal gå ut på. Og i praksis ligner nok spesifikasjonen også for slike prosjekter mer på den tradisjonelle kravspesifikasjonen enn «reklamen» gir inntrykk av. Men en slik utviklingsmodell forutsettes at flere spørsmål avklares under marsjen. Man må fortsatt angi retningen og målene, mens man i større grad lar veien bli til mens man går. Tilhengerne av en slik utviklingsmodell hevder at man på denne måten kommer raskere til målet, slik at utviklingen tar kortere tid og bli billigere. Det er meget mulig at dette er riktig, og jeg har ingen forutsetninger for å vurdere dette. For kunden betyr det at man i større grad må stole på at man underveis er i stand til å finne veien til målet, og det er vanskeligere å avtale en fast pris når prosjektet er organisert på denne måten. Kunden kan altså få en utviklingsmodell som i mange tilfeller sannsynligvis vil bringe en raskere til målet, men man ofrer den sikkerhet og forutsigbarhet som ligger i en detaljert kravspesifikasjon og fast pris.

I løpet av et utviklingsprosjekt som varer noe tid, må man regne med betydelige ytelsesforbedringer for det utstyr som skal benyttes, f.eks. raskere prosessorer og ellers økt maskinkapasitet. Slike ytelsesforbedringer representerer ikke noen problemer. Endringer i funksjonalitet eller i teknologisk plattform er langt mer risikabelt.

Det er vanskelig å dele opp et IT-prosjekt slik at forskjellige leverandører får i oppgave å utvikle ulike komponenter. Man må i alle fall ha en meget god overordnet prosjektstyring, slik at man sikrer seg at de enkelte komponentene passer sammen. Hvis kunden ikke selv har kompetanse til å styre et stort prosjekt, kan man være tjent med å inngå avtale med en «hovedentreprenør» som har ansvar både for «arkitektur», detaljprosjektering og produksjon. Avtalen må da inngås i tillit til at uløste problemer blir løst underveis. En slik leverandør kaller seg gjerne «systemintegrator».

Det er derimot enkelt å skille utvikling av programvare fra levering av utstyr og standardprogrammer. Det er ingen grunn til å koble utvikling av programvare med levering av PC'er som skal stå på de ansattes arbeidsplasser, skrivere, etc.

Noen bøker om IT-kontrakter


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 >>
Kontrakter for utvikling av programvare
Boka tar for seg utviklingskontrakter for dataprogramvare.
RefNr: 9788202196912
Bestill fra:
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: InnledningNext page: Resultat- og omsorgsforpliktelse Next page:

Next page: Resultat- og omsorgsforpliktelse Next page:

Previous page: Previous page: Innledning