Hvor langt bør funksjoner som ikke er spesifisert i systemutviklingsdokumentasjonen implementeres i henhold til loven?

Prosjekter for utvikling av IT-systemer som brukes i bedrifter, blir i prinsippet laget i henhold til forhåndsdefinerte spesifikasjoner. Men på den annen side, hvis vi vurderer betydningen av at leverandøren er betrodd utviklingsarbeidet som en ekspert på systemutvikling, kan det hende at brukernes forventninger ikke er så lave at det er tilstrekkelig å bare implementere det som er skrevet i spesifikasjonene mekanisk. I denne artikkelen vil vi forklare hvor langt man bør gå i å påta seg plikten til å implementere programmer som ikke er nevnt i spesifikasjonene, men som er nødvendige for å oppfylle utviklingsformålet.

Juridiske problemer knyttet til implementering av ikke-spesifiserte funksjoner

Leverandørens arbeid krever skjønn

En stor egenskap ved kontrakter knyttet til systemutviklingsprosjekter og de tilhørende juridiske problemene er at leverandøren som påtar seg arbeidet, har betydelig skjønn.

Relatert artikkel: Hva er prosjektledelsesplikter i systemutvikling?[ja]

Det er imidlertid viktig å merke seg at “skjønn” i denne sammenhengen ikke nødvendigvis gjelder for alle faser av systemutviklingsprosessen. Etter å ha identifisert hver fase og brutt dem ned i detaljerte oppgaver, kan det være mange oppgaver som ligner enkle arbeidsoppgaver. Generelt sett, jo tidligere i prosessen, desto mer skjønn kreves for å utføre arbeidet. Dette er også grunnen til at de tidlige fasene ofte passer godt med kontraktstyper som oppdragsavtaler.

Relatert artikkel: Forskjellen mellom oppdragsavtaler og oppdragsbaserte kontrakter i systemutvikling[ja]

Skjønn bør utøves innenfor strenge utviklingsprosesser

Selv om leverandøren har betydelig skjønn i systemutvikling, kan det å ukritisk akseptere klientens ønsker føre til store problemer i senere faser. Et IT-system består av mange små komponenter, og selv små endringer kan kreve betydelige endringer i arbeidsmengden fra utviklerens perspektiv. For mer informasjon om hvordan man håndterer endringer i systemutviklingsspesifikasjoner fra et juridisk perspektiv, se følgende artikkel. Denne artikkelen forklarer hvordan man håndterer endringer, og diskuterer også hvor stor innvirkning spesifikasjonsendringer kan ha på arbeidet fra en teknikers perspektiv.

Relatert artikkel: Hvordan håndtere endringer i systemutvikling fra et juridisk perspektiv[ja]

Hva bør gjøres som en ekspert, uten å være bundet av spesifikasjoner?

For å sikre en smidig fremdrift i systemutviklingsprosjekter er det viktig å definere utviklingskravene på forhånd og planlegge i henhold til dem. Samtidig er det situasjoner der det ikke er tilstrekkelig å bare følge de forhåndsdefinerte kravene for å oppfylle rollen som systemutviklingsekspert. I denne dilemmaet oppstår spørsmålet om hva som bør implementeres, selv om det ikke er spesifisert i kravene.

Juridiske forpliktelser bestemmes i henhold til intensjonen i spesifikasjoner og kontrakter

Innholdet av det som skal implementeres, bestemmes ut fra intensjonen i kontrakter og spesifikasjoner, selv om det ikke er eksplisitt nevnt i disse dokumentene. Med andre ord, det avgjøres ut fra hva slags mening eller hensikt som ligger bak de avtalte bestemmelsene. La oss se på noen rettspraksis-eksempler nedenfor.

Rettstilfelle der implementeringsplikt ble avvist på grunn av manglende spesifikasjon

I det siterte rettstilfellet nedenfor, utviklet en leverandør et system som nådde en midlertidig driftsfase, men det oppsto en tvist da kunden krevde å kansellere kontrakten på grunn av manglende nødvendige funksjoner. Kunden hevdet at den manglende funksjonen var “automatisk dataoppdatering”, som ble påstått å være et hovedsalgsargument for systemet. Retten anerkjente imidlertid ikke denne implementeringsplikten.

Som fastslått ovenfor, er det ingen indikasjon i den aktuelle kontrakten, grunnleggende designspesifikasjonen eller detaljdesignspesifikasjonen på at funksjon ③ var en del av systemutviklingen.

Saksøkeren hevder at funksjon ③ var et hovedsalgsargument for systemet som ble levert av saksøkte, og understreker nødvendigheten av denne funksjonen. Hvis denne påstanden var korrekt, ville dette ha vært tydelig spesifisert i kontrakten, og uten en slik spesifikasjon er det vanskelig å tro at utviklingen av denne funksjonen var avtalt.

Tokyo District Court, 18. februar Heisei 21 (2009)

Domfellelsen kan enkelt oppsummeres som “hvis det ikke er spesifisert i designspesifikasjonen, trenger det ikke å utvikles”. Men mer presist, bør det sies at avgjørelsen ble tatt basert på “hensikten” med spesifikasjonene i design- og kontraktsdokumentene, snarere enn bare det formelle faktum om hvorvidt det var spesifisert. Med andre ord, det er rimelig å anta at det ikke var noen avtale om utviklingen av funksjonen, gitt at det ikke var spesifisert i design- eller kontraktsdokumentene.

Rettseksempler der implementeringsplikt ble bekreftet selv uten spesifikasjon

På den annen side finnes det rettseksempler som bekrefter plikten til å implementere, selv om det ikke var spesifisert i kontrakten eller spesifikasjonene. Det følgende rettseksempelet omhandler utviklingen av et system for å administrere medisinbrukshistorikk, hvor dataoverføring fra det eksisterende systemet til det nye systemet ikke ble gjennomført. Dette førte til at brukeren ikke kunne benytte det nye systemet og derfor hevet kontrakten. Leverandøren hevdet imidlertid at dataoverføring lå utenfor deres ansvarsområde, noe som førte til en tvist.

Utvikling av nye systemer innebærer ofte avvikling av eksisterende systemer og dataoverføring. Viktigheten av slike oppgaver og de tilhørende juridiske problemene er detaljert forklart i følgende artikkel.

Relaterte artikler: Juridiske problemer ved overgang fra gamle systemer i systemutvikling[ja]

Det eksisterende systemet hadde allerede lagret data for over 50 000 pasienter, og saksøker brukte disse dataene for å effektivisere administrasjonen. Hvis det ikke var mulig å overføre pasientdataene fra det eksisterende systemet til det nye systemet, ville det åpenbart forstyrre apotekets dispensasjonsarbeid, og det er rimelig å anta at saksøkers representant var klar over dette. Videre, før kontrakten ble inngått, spurte saksøkers representant saksøktes representant om muligheten for dataoverføring, noe saksøktes representant også innrømmet (utdrag). Det er vanskelig å tro at saksøkers representant ville ha bestemt seg for å implementere det nye systemet, vel vitende om at det var en høy sannsynlighet for at de måtte taste inn data for over 50 000 pasienter manuelt. I tillegg, som nevnt i punkt (1) i, kunne saksøkte ikke overføre medisinbrukshistorikkdataene fra det eksisterende systemet til det nye systemet, og behandlet derfor dataene ved å skrive dem ut på papir og deretter skanne dem til PDF-filer. Selv om dataoverføring ikke var en forutsetning i kontrakten, er det vanskelig å tro at saksøkte ville ha utført en så tidkrevende oppgave som en tjeneste.

Tokyo District Court, 18. november Heisei 22 (2010)

Det som er viktig her, er formålet med kontrakten og “hensikten” med kontraktens bestemmelser. Hvis begge parter inngikk kontrakten med forståelsen av at dataoverføring lå utenfor arbeidsområdet, ville det bety at både brukeren og leverandøren inngikk kontrakten med en unaturlig intensjon, noe retten påpekte. Det vil si at brukeren ville ha påtatt seg en enorm mengde manuelt arbeid, og leverandøren ville ha gått inn i prosjektet vel vitende om at det ville forstyrre brukerens arbeid, noe som er svært urimelig.

Hva vi kan lære av begge dommene

Selv om kontrakten eller spesifikasjonene ikke nevnte dataoverføring, ble plikten til å implementere dette bekreftet. En av grunnene til dette er at det handlet om “data”, som ikke vises på skjermen. Mangelen på “nødvendige funksjoner” er derimot noe som vises direkte på systemets skjerm og utseende. Derfor er det ikke så vanskelig å oppdage mangler i spesifikasjonene, selv for en som ikke er ekspert på systemutvikling. På den annen side er det vanskeligere for en ikke-ekspert å forstå viktigheten av dataoverføring, samt vanskelighetsgraden og arbeidsmengden som kreves. Derfor ble det ansett som noe leverandøren, med sin ekspertise, burde håndtere smidig.

Med dette i tankene kan vi si at mangler i spesifikasjonene eller kontrakten er nært knyttet til brukerens “samarbeidsplikt”. Spørsmålet er om brukeren virkelig har oppfylt sin “samarbeidsplikt” i forbindelse med inngåelsen av kontrakten og utarbeidelsen av spesifikasjonene. En generell forklaring på de juridiske forpliktelsene brukeren har i et systemutviklingsprosjekt, finner du i artikkelen nedenfor.

Relatert artikkel: Hva er samarbeidsplikten til brukeren som bestiller systemutvikling?[ja]

Ved å lese den ovennevnte artikkelen, vil du også forstå at det er en stor forskjell mellom brukerens samarbeid i forbindelse med identifisering av skjermbilder og nødvendige funksjoner, og mangler i vurderingen av dataoverføring.

Hvordan bør man vurdere godtgjørelse for utvikling som ikke er spesifisert i spesifikasjonen?

Et annet relevant spørsmål i forbindelse med dette temaet er om det er lovlig å kreve ekstra godtgjørelse for arbeid som ikke er spesifisert i spesifikasjonen. Vi forklarer detaljert om muligheten for å øke godtgjørelsen og hvordan man beregner estimert beløp i følgende artikkel.

Relatert artikkel: Er det mulig å øke estimert beløp for systemutvikling etterpå?[ja]

I artikkelen ovenfor forklarer vi at det er viktig å vurdere om det har vært arbeid som overstiger det opprinnelige arbeidsomfanget i forhold til godtgjørelsen. Med andre ord, i forhold til denne artikkelen, hvis leverandøren går med på å utvikle noe som ikke er inkludert i den opprinnelige spesifikasjonen (i denne artikkelen referert til som et negativt eksempel), kan man kreve ekstra godtgjørelse for dette.

Oppsummering

Ved systemutvikling bestemmes leverandørens rolle delvis av innholdet i kontrakter og spesifikasjoner. Men, når man tar i betraktning at leverandøren er betrodd oppgaver basert på høy tillit som eksperter, forstår man at realiteten ikke kun bestemmes av formelle dokumenter. Det er viktig å forstå at lovene spiller en betydelig rolle i å forstå denne realiteten.