Hur långt ska man juridiskt implementera funktioner som inte finns i specifikationerna för systemutveckling?

Projekt som utvecklar IT-system som används i företag skapas i princip enligt fördefinierade specifikationer. Men å andra sidan, om man tänker på vad det innebär att en leverantör har fått fullt ansvar för systemutveckling som en expert, kanske användarens förväntningar inte är så låga att det räcker att bara mekaniskt implementera det som är skrivet i specifikationerna. I denna artikel kommer vi att diskutera hur mycket ansvar man bör ta för att implementera ett program som “inte är specificerat i specifikationerna, men som behöver implementeras med tanke på utvecklingsmålet”.

Rättsliga problem i samband med implementering av icke-specifierade funktioner

En leverantörs arbete kräver diskretion

En av de stora egenskaperna hos kontrakt och diverse juridiska problem relaterade till systemutvecklingsprojekt är att leverantören som tar emot arbetet har stor diskretion.

Relaterad artikel: Vad är projektledningsskyldigheter i systemutveckling[ja]

Emellertid gäller “diskretion” inte nödvändigtvis för alla steg i systemutvecklingsprocessen. Efter att ha identifierat varje steg och gått vidare med att bryta ner dem i detaljerade uppgifter, kan det bli mer likt enkelt arbete. Men generellt sett, ju mer det blir en uppgift i den tidiga fasen, desto svårare blir det att utföra arbetet utan stor diskretion. Det är också därför det ofta passar bra med en quasi-delegation som kontraktstyp i de tidiga faserna.

Relaterad artikel: Skillnaden och distinktionen mellan kontrakt och quasi-delegation i systemutveckling[ja]

Diskretion bör också utövas inom stränga utvecklingsprocesser

Även om leverantören som utvecklar systemet har stor diskretion, att acceptera kundens önskemål på ett oorganiserat sätt kan orsaka stor skada i senare steg. Ett IT-system består av många små delar, så även om det bara är en liten förändring i utseendet, kan det kräva en stor förändring i arbetsbelastningen från utvecklarens perspektiv. Dessutom finns det artiklar som förklarar hur man hanterar ändringar i systemutvecklingsspecifikationer från en juridisk synvinkel. Följande artikel diskuterar hur man hanterar ändringskontroll, men diskuterar också hur mycket en ändring i specifikationerna kan påverka arbetet från en ingenjörs perspektiv.

Relaterad artikel: Hur man hanterar ändringskontroll i systemutveckling från ett juridiskt perspektiv[ja]

Vad bör en expert göra utan att vara bunden av specifikationer?

För att smidigt driva ett systemutvecklingsprojekt är det viktigt att definiera utvecklingskraven i förväg och följa dem på ett planerat sätt. Å andra sidan finns det situationer där du inte kan fullgöra din roll som en expert inom systemutveckling genom att bara göra vad du har blivit tillsagd att göra enligt de fördefinierade kraven. I denna dilemma kommer problemet med “vad som bör implementeras, även om det inte anges i specifikationerna” att framträda.

Rättsliga skyldigheter bestäms enligt ‘syftet’ med specifikationer och kontrakt

Innehållet i det som ska implementeras bestäms, även om det inte finns någon anteckning i kontraktet eller specifikationerna, fortfarande från ‘syftet’ med dessa kontrakt och specifikationer, det vill säga, ‘vilken mening eller avsikt hade de när de kom överens på det sättet’. Låt oss titta på några rättsfall nedan.

Rättsfall där implementeringsplikten förnekades på grund av brist på anteckningar

I det rättsfall som citeras nedan utvecklade en leverantör ett system som hade gått fram till provdrift, men det uppstod en tvist när det begärdes att avtalet skulle upphävas eftersom de nödvändiga funktionerna saknades. Användaren hävdade att “automatisk datauppdateringsfunktion” saknades, vilket hävdades vara en viktig försäljningspunkt för detta system, men domstolen erkände inte denna implementeringsskyldighet.

Som erkänt ovan finns det ingen anteckning i detta avtal, grundläggande design dokument och detaljerade design dokument som visar att funktion ③ är ett utvecklingsmål för detta system.

Även om käranden hävdar att funktion ③ var en viktig försäljningspunkt för svarandens system till käranden och betonar behovet av denna funktion, om detta var fallet borde det ha varit klart angivet i detta avtal etc., det är svårt att tro att utvecklingen av denna funktion hade kommit överens om det inte var så.

Tokyo District Court, February 18, Heisei 21 (2009)

Detta domslut kan säkert sägas vara enkelt om man bara tar ut slutsatsen, “om det inte finns någon anteckning i design dokumentet, behöver du inte skapa något som inte finns”. Men mer exakt bör det sägas att det inte var en formell faktum om det fanns en anteckning i design dokumentet eller inte, utan ett beslut baserat på “syftet” med anteckningen i design dokumentet och kontraktet. Med andra ord, “om man tänker på varför det inte fanns någon anteckning i design dokumentet och kontraktet, är det rimligt att tro att det inte fanns något avtal som motsvarade den anteckningen”.

Rättsfall där implementeringsansvaret bekräftades trots brist på dokumentation

Å andra sidan finns det rättsfall där implementeringsansvaret har erkänts även om det inte fanns någon dokumentation i kontraktet eller specifikationerna. Rättsfallet som citeras nedan handlar om utvecklingen av ett system för att hantera medicineringshistorik. Användaren kunde inte överföra data från det befintliga systemet till det nya systemet, vilket gjorde det omöjligt att använda det nya systemet och ledde till att användaren avbröt kontraktet. Men leverantören hävdade att dataöverföringen låg utanför deras ansvarsområde, vilket ledde till en tvist.

Utvecklingen av nya system innebär ofta att befintliga system avvecklas och att data överförs. Vi har detaljerat förklarat vikten av dessa uppgifter och de juridiska problem som följer med dem i artikeln nedan.

Relaterad artikel: Juridiska problem i samband med övergången från gamla system vid systemutveckling[ja]

Det befintliga systemet innehöll redan data för över 50 000 patienter, och eftersom klaganden använde dessa data för att effektivisera administrationen, skulle det vara uppenbart att apotekets verksamhet skulle störas om patientdata inte kunde överföras från det befintliga systemet till det aktuella systemet. Det kan antas att klagandens representant var medveten om detta. Dessutom, innan kontraktet ingicks, frågade klagandens representant svarandens representant om det var möjligt att överföra data, vilket svarandens representant erkände (utelämnat). Det är svårt att tro att klagandens representant, medveten om att det skulle vara nödvändigt att manuellt mata in data för över 50 000 patienter, ändå beslutade att införa det aktuella systemet. Dessutom, som nämnts ovan i (1)I, eftersom svaranden inte kunde överföra det befintliga systemets medicineringshistorikdata till det aktuella systemet, och i stället skrev ut data på papper och införde det i en PDF-fil, är det svårt att tro att svaranden skulle ha utfört denna tidskrävande uppgift som en tjänst, trots att dataöverföring inte antogs i det aktuella kontraktet.

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

Det som är viktigt här är kontraktets syfte och “meningen” med de punkter som anges i kontraktet. Om båda parter ingick kontraktet med förståelsen att dataöverföringen låg utanför arbetsområdet, skulle det innebära att både användaren och leverantören ingick kontraktet med onaturliga avsikter. Det vill säga, användaren skulle ha tagit på sig en enorm mängd manuellt arbete, och leverantören skulle ha gått in i projektet med vetskap om att det skulle störa användarens verksamhet i framtiden, vilket skulle vara mycket orimligt.

Vad vi kan lära oss från båda domarna

Även om det inte finns någon anteckning i kontraktet eller specifikationerna om dataöverföring, tror vi att en av anledningarna till att implementeringsplikten bekräftades var att det handlade om “data”, en fråga som inte visas på skärmen. Den tidigare nämnda “bristen på nödvändiga funktioner” är något som direkt visas på systemets skärm och utseende. Därför är det inte särskilt svårt att upptäcka utelämnande av specifikationer, även för en amatör inom systemutveckling. Å andra sidan har dataöverföringsproblemet egenskapen att det är svårt för en amatör inom systemutveckling att känna igen vikten av processen, svårighetsgraden av arbetet och tiden det tar. Därför tror vi att det fanns omständigheter där det var lätt att behandla det som en fråga som leverantören borde hantera smidigt med sin expertis.

Om man tänker på det på detta sätt, kan utelämnandet av specifikationer och kontrakt vara ett problem som är nära kopplat till användarens “skyldighet att samarbeta”. Med andra ord, har användaren verkligen uppfyllt sin “skyldighet att samarbeta” i samband med ingåendet av kontraktet och skapandet av specifikationerna? En övergripande förklaring av de juridiska skyldigheter som användaren bör uppfylla i ett systemutvecklingsprojekt finns i följande artikel.

Relaterad artikel: Vad är samarbetsplikten som användaren, som är beställaren av systemutveckling, har att bära?[ja]

Om du också kontrollerar artikeln ovan, kommer du förmodligen att förstå att diskussionen skiljer sig mycket mellan områden där användarens samarbetsbegäran, som identifiering av skärm- och nödvändiga funktioner, är stor och utelämnandet av dataöverföringsöverväganden.

Hur bör man tänka kring ersättning för utveckling som inte specificeras i specifikationen?

En annan fråga som kan uppstå i samband med ämnet för denna artikel är om det är lagligt att begära extra ersättning för att ha skapat något som inte specificerades i specifikationen. Vi diskuterar detaljerat om möjligheten att öka ersättningen och hur man beräknar kostnadsförslaget i sådana fall i följande artikel.

Relaterad artikel: Är det möjligt att öka kostnadsförslaget för systemutveckling i efterhand?[ja]

I ovanstående artikel förklarar vi att det är viktigt att avgöra om det fanns arbete som översteg arbetsomfånget i förhållande till ersättningen. Med andra ord, i samband med denna artikel, om leverantören tar på sig utvecklingen av något som inte ingick i den ursprungliga specifikationen (det vill säga, det negativa exemplet i denna artikel), kan de begära extra ersättning.

Sammanfattning

I systemutveckling är rollen som en leverantör bör spela i viss mån bestämd av innehållet i kontrakt och specifikationer. Men med tanke på att de är experter som har fått uppdraget på grund av hög tillit, är det klart att deras faktiska roll inte bara bestäms av formaliteter. Ändå bör vi förstå att lagen spelar en stor roll även när det gäller att förstå deras faktiska situation.