Hvor meget skal man juridisk set implementere funktioner, der ikke er i specifikationerne for systemudvikling?

Projekter, der udvikler IT-systemer, der anvendes i virksomheder, er som hovedregel skabt i overensstemmelse med foruddefinerede specifikationer. Men på den anden side, når man tager i betragtning, at leverandøren er betroet udviklingsopgaverne som en ekspert i systemudvikling, kan brugernes forventninger måske ikke være så lave, at det kun er nødvendigt at implementere det, der er skrevet i specifikationerne, mekanisk. I denne artikel vil vi forklare, i hvilket omfang man bør påtage sig ansvaret for at implementere et program, der “ikke er beskrevet i specifikationerne, men er nødvendigt at implementere i lyset af udviklingsmålene”.

Juridiske problemer forbundet med implementering af ikke-specificerede elementer

Der kræves skøn i leverandørens arbejde

En stor karakteristik ved kontrakter omkring projekter som systemudvikling og de forskellige juridiske problemer, der følger med, er, at leverandøren, der modtager arbejdet, har stor skønsmæssig beføjelse.

Relateret artikel: Hvad er projektledelsesforpligtelser i systemudvikling[ja]

Men “skøn”, som det er nævnt her, gælder ikke nødvendigvis for alle trin i systemudviklingsprocessen. Efter at have identificeret hver proces og fremmet identifikationen af detaljerede opgaver, kan der være mange opgaver, der er tæt på simpelt arbejde. Men generelt, jo mere det bliver arbejde i de tidlige faser, dvs. opstrømsprocesser, jo sværere bliver det at udføre arbejdet uden at have stor skøn. En af grundene til, at opstrømsprocesser ofte passer godt til semi-delegation som en kontrakttype, kan også siges at være på grund af dette.

Relateret artikel: Forskellen og forskellen mellem kontrakt og semi-delegation kontrakt i systemudvikling[ja]

Skøn bør også udøves inden for strenge udviklingsprocesser

Men selvom leverandøren, der udvikler systemet, har stor skøn, vil det at acceptere kundens ønsker på en “ad hoc” måde forårsage stor skade i de senere faser. Et IT-system er lavet af en samling af små dele, så selvom det kun kan være en lille ændring i udseendet, kan der være tilfælde, hvor det kræver en betydelig ændring i arbejdstiden fra udviklerens synspunkt. Der er også artikler, der forklarer, hvordan man håndterer ændringsstyring fra et juridisk synspunkt med hensyn til ændringer i systemudviklingsspecifikationer. Den følgende artikel forklarer, hvordan man håndterer ændringsstyring, men diskuterer også, hvor meget en ændring i specifikationerne kan påvirke arbejdet fra en ingeniørs synspunkt.

Relateret artikel: Hvad er måden at håndtere ændringsstyring i systemudvikling fra et juridisk synspunkt[ja]

Hvad skal en ekspert gøre uden at være bundet af specifikationer?

For at fremme et systemudviklingsprojekt glat er det vigtigt at definere udviklingskravene på forhånd og fortsætte planmæssigt i overensstemmelse hermed. På den anden side er der også situationer, hvor du ikke kan fuldt ud udføre din rolle som en ekspert i systemudvikling ved blot at gøre, hvad du er blevet fortalt i overensstemmelse med de krav, der er defineret på forhånd. I denne dilemma kommer problemet med “hvad der skal implementeres, selvom det ikke er angivet i specifikationerne” til syne.

Juridiske forpligtelser bestemmes i overensstemmelse med ‘formålet’ med specifikationer og kontrakter

Indholdet af det, der skal implementeres, bestemmes, selvom det ikke er angivet i kontrakten eller specifikationerne, stadig fra ‘formålet’ med disse kontrakter og specifikationer, det vil sige, ‘hvad var meningen eller hensigten med at træffe sådanne aftaler’. Lad os se på nogle retssager nedenfor.

Retssag, hvor implementeringspligten blev afvist på grund af manglende beskrivelse

I den retssag, der citeres nedenfor, udviklede en leverandør et system, der var kommet så langt som til prøvedrift, men der opstod en konflikt, da der blev krævet ophævelse af kontrakten, fordi de nødvendige funktioner manglede. Det, som brugeren hævdede manglede, var “automatisk dataopdateringsfunktion”, og det blev hævdet, at dette var et hovedsalgspunkt for det pågældende system, men retten anerkendte ikke denne implementeringspligt.

Som anerkendt ovenfor, er der ingen beskrivelse i den pågældende kontrakt, grundlæggende design dokument og detaljerede design dokument, der indikerer, at funktion ③ er et udviklingsmål for det pågældende system.

Sagsøgeren hævder, at funktion ③ var et hovedsalgspunkt for sagsøgtes system over for sagsøgeren, og understreger behovet for denne funktion, men hvis denne påstand er korrekt, skulle det have været klart angivet i den pågældende kontrakt osv., og det er svært at tro, at udviklingen af denne funktion blev aftalt, når det ikke er tilfældet.

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

Denne dom kan bestemt, hvis man blot tager konklusionen ud i sin simple form, siges at være “hvis det ikke er beskrevet i design dokumentet, behøver man ikke at lave det, der ikke er der”. Men mere præcist, det er ikke en formel kendsgerning, om det er beskrevet i design dokumentet eller ej, men en dom baseret på “formålet” med beskrivelsen i design dokumentet og kontrakten. Det vil sige, “hvis man tager hensyn til grunden til, at det ikke blev beskrevet i design dokumentet og kontrakten, er det rimeligt at antage, at der heller ikke var en aftale, der svarede til denne beskrivelse”.

Retssager, hvor implementeringspligten blev bekræftet, selvom det ikke var angivet

På den anden side er der retssager, der har fastslået, at der bør være en pligt til at implementere, selvom det ikke var angivet i kontrakten eller specifikationerne. Den retssag, jeg citerer nedenfor, handler om udviklingen af et system til at styre medicinindtagshistorik, hvor det ikke var muligt at overføre data fra det eksisterende system til det nye system, og brugeren kunne ikke udnytte det nye system og valgte at opsige kontrakten. Men leverandøren argumenterede for, at dataoverførsel var uden for deres arbejdsområde, hvilket førte til en konflikt.

Udviklingen af nye systemer indebærer ofte afskaffelsen af eksisterende systemer og overførsel af data. Vi har detaljeret forklaret vigtigheden af disse opgaver og de juridiske problemer, der følger med dem, i artiklen nedenfor.

Relateret artikel: Juridiske problemer i forbindelse med overgangen fra det gamle system ved systemudvikling[ja]

Der er allerede gemt data for mere end 50.000 patienter i det eksisterende system, og det er klart, at hvis det ikke er muligt at overføre patientdata fra det eksisterende system til det nye system, vil det forstyrre apotekets dispensering. Det kan antages, at sagsøgerens repræsentant naturligvis var klar over dette. Og før kontrakten blev indgået, spurgte sagsøgerens repræsentant sagsøgtes repræsentant om muligheden for dataoverførsel, hvilket sagsøgtes repræsentant også anerkendte (udeladelse), sagsøgerens repræsentant, det er meget usandsynligt, at han besluttede at introducere det nye system, selvom han var klar over, at han sandsynligvis skulle indtaste data for mere end 50.000 patienter manuelt. Desuden, som nævnt ovenfor i (1)I, er det usandsynligt, at sagsøgte, der ikke kunne overføre medicinhistorikdata fra det eksisterende system til det nye system, og derfor behandlede disse data ved at printe dem ud på papir og indføre dem i en PDF-fil, ville have udført sådan et tidskrævende arbejde som en service, selvom dataoverførsel ikke var forudsat i kontrakten.

Tokyo District Court, November 18, 2010 (Heisei 22)

Det, der er vigtigt her, er formålet med kontrakten og “hensigten” med de punkter, der er angivet i kontrakten. Hvis begge parter indgik kontrakten med forståelsen af, at dataoverførsel var uden for arbejdsområdet, ville det betyde, at både brugeren og leverandøren indgik kontrakten med en unaturlig hensigt. Det vil sige, at brugeren ville have accepteret en enorm mængde manuelt arbejde, og leverandøren ville have påtaget sig projektet, vel vidende at det ville forstyrre brugerens arbejde i fremtiden, hvilket ville være meget urimeligt.

Hvad vi kan lære af begge domme

Selvom der ikke var nogen omtale af dataoverførsel i kontrakten eller specifikationerne, blev implementeringsforpligtelsen bekræftet. En af grundene til dette kan være, at det handlede om “data”, et emne, der ikke vises på skærmen. Manglen på “nødvendige funktioner” er noget, der direkte vises på systemets skærm og interface. Derfor er det ikke særlig svært, selv for en novice inden for systemudvikling, at opdage mangler i specifikationerne. På den anden side er problemet med dataoverførsel karakteriseret ved, at det er svært for en novice inden for systemudvikling at genkende vigtigheden af processen, kompleksiteten af opgaven og den tid, det tager. Derfor kan det antages, at der også var en situation, hvor det blev behandlet som noget, som leverandørsiden skulle styre effektivt med deres ekspertise.

Når man tænker på det på denne måde, kan mangler i specifikationer og kontrakter også siges at være tæt forbundet med brugerens “forpligtelse til at samarbejde”. Med andre ord, det er et spørgsmål om, hvorvidt brugeren virkelig har opfyldt sin “forpligtelse til at samarbejde” i forbindelse med indgåelse af kontrakten og udarbejdelse af specifikationerne. En generel forklaring på de juridiske forpligtelser, som brugeren skal opfylde i et systemudviklingsprojekt, er detaljeret behandlet i følgende artikel.

Relateret artikel: Hvad er brugerens samarbejdsforpligtelse i systemudvikling?[ja]

Hvis du også tjekker den ovenstående artikel, vil du forstå, at områder, hvor der er stor efterspørgsel efter brugerens samarbejde, såsom identifikation af skærm- og nødvendige funktioner, og manglende overvejelser om dataoverførsel, er meget forskellige.

Hvordan skal man tænke på betaling for udvikling, der ikke er specificeret i specifikationerne?

Et andet spørgsmål, der kan opstå i forbindelse med emnet for denne artikel, er, om det er juridisk tilladt at anmode om ekstra betaling, hvis man har lavet noget, der ikke er specificeret i specifikationerne. Vi har en detaljeret forklaring på, om det er muligt at øge betalingen, og hvordan man beregner det estimerede beløb i så fald, i artiklen nedenfor.

Relateret artikel: Er det muligt at øge det estimerede beløb for systemudvikling efterfølgende?[ja]

I ovenstående artikel forklarer vi, at det er vigtigt, om der har været opgaver, der overstiger arbejdsområdet, der er relateret til betalingen. Det vil sige, i forhold til denne artikel, hvis leverandøren har reageret på udviklingen af noget, der ikke var inkluderet i de oprindelige specifikationer (i denne artikel, den negative eksempel), så er det muligt at anerkende en anmodning om ekstra betaling.

Opsummering

I systemudvikling er den rolle, som en leverandør skal spille, på den ene side bestemt i overensstemmelse med indholdet af kontrakter og specifikationer. Men når man tager i betragtning, at de er betroet med arbejde baseret på høj tillid som eksperter, bliver det klart, at deres faktiske situation ikke nødvendigvis er bestemt af formaliteter. Ikke desto mindre bør man forstå, at loven spiller en stor rolle, selv når man forsøger at forstå denne indre virkelighed.