Vad innebär samarbetsplikten för användaren som beställer systemutveckling?

Arbetet med systemutveckling kräver, ju större systemet som ska utvecklas är, desto mer personal och tid. Därför finns det en viss skyldighet till samarbete inte bara från leverantörens sida som tar emot utvecklingsuppdraget, utan också från användarens sida som beställer systemutvecklingen.

Detta skiljer sig från den vanliga beställningsrelationen. Till exempel, om du ber en skräddare att skapa en skräddarsydd kostym istället för ett IT-system, har kunden (användaren) som beställer inte någon särskild “skyldighet”. Det är främst skräddaren (leverantören) som har “skyldigheten”. Just på grund av att IT-system kräver mycket personal och tid, finns det ett behov för användaren att “samarbeta” med leverantören.

I denna artikel kommer vi att förklara vilka juridiska skyldigheter som finns för beställaren när det gäller systemutveckling, vilket inte kan lämnas enbart till leverantören.

Det räcker inte att bara “kasta bollen” när det gäller ditt eget system

Även om det handlar om ett enda systemutvecklingsprojekt, är det ofta många människor och organisationer inblandade. Det är självklart viktigt med ingenjörer och programmerare som är skickliga på kodning, men för att sammanföra deras arbete till ett enda resultat, spelar projektledarens roll också en viktig roll.

Men, oavsett hur hög teknisk och organisatorisk förmåga leverantören har, kan systemutvecklingen inte slutföras enbart med leverantörens kraft. Till exempel, det finns ingen möjlighet för leverantören att känna till interna termer som endast används inom företaget, eller företagsspecifik affärskunskap, genom enkelriktade ansträngningar från leverantörens sida. Ju större systemutveckling, desto mer sannolikt är det att företaget som kommer att använda systemet är ett stort företag med många anställda och arbetsuppgifter. För att leda ett systemutvecklingsprojekt till framgång, är det ofta fallet att organiseringen av denna affärslogik faktiskt har en stor vikt, snarare än datorarbete.

Därför, istället för att användarna blir passiva med motiveringen att “jag är inte en IT-expert”, kan projektet gå smidigare genom att de aktivt tillhandahåller information. I detta avseende är den roll som användarna spelar i ett systemutvecklingsprojekt faktiskt inte liten alls.

Vad innebär användarens samarbetsplikt baserat på rättsfall?

Så vad innebär konkret samarbetsplikten som användaren har i systemutvecklingsprojekt? Det finns många ledtrådar i tidigare rättsfall om detta.

I domstolen blev frågan om användarens samarbetsplikt i utvecklingen en tvistepunkt när leverantörens (svarandens) leveranstid försenades på grund av användarens (kärandens) beslutsfördröjning. I detta fall erkände domstolen att användaren hade brutit mot sin samarbetsplikt och förnekade leverantörens ansvar för kontraktsbrott. (Även om upplösningen av kontraktet erkändes, erkändes också en 60% felkompensation.)

I detta fall av systemutvecklingskontrakt, som är ett så kallat skräddarsytt systemutvecklingskontrakt, kan inte leverantören (leverantören) slutföra systemet på egen hand, och uppdragsgivaren (användaren) måste under utvecklingsprocessen korrekt samordna interna åsikter, ena åsikterna, klart kommunicera till leverantören vilka funktioner de vill ha, och tillsammans med leverantören, överväga de önskade funktionerna, slutligen bestämma funktionerna, och dessutom, bestämma skärmen och rapporterna, och dela rollen att acceptera de färdiga produkterna.

Tokyo District Court, March 10, Heisei 16 (2004)

Denna dom är mycket suggestiv, inte bara för att den indikerar att systemutveckling i sig är ett gemensamt arbete med användaren, utan också för att den klargör “vilka specifika punkter som bör samarbetas på”.

Låt oss försöka översätta ordalydelsen i ovanstående dom till IT-termer för systemutveckling.

Dessa kan organiseras på detta sätt. Oavsett hur avancerad expertis på IT-system, kan dessa inte göras ensamma utan användarens samarbete. Vilka funktioner som efterfrågas och hur skärmlayouten ska se ut är i grunden saker som användaren bör klargöra, och om det som efterfrågades har realiserats eller inte kan bara användaren bekräfta.

Det bör noteras att precis som leverantören har en skyldighet att hantera projektet, har användaren också en samarbetsplikt. Om användaren bryter mot sin samarbetsplikt i processen som beskrivs ovan, finns det en risk att leverantören kan begära skadestånd från användaren för kontraktsbrott eller olagliga handlingar.

Hur tolkas efterfrågningar om specifikationsändringar efteråt?

Om vi antar att systemutvecklingsprojekt är ett gemensamt arbete mellan användare och leverantör, kommer diskussionen att utvecklas ytterligare. Frågan är, “Vem är ansvarig om användaren efteråt begär tillägg eller ändringar, vilket gör det svårt att uppfylla leveranstiden?”

Systemutveckling börjar generellt med kravspecifikation, följt av grundläggande design, detaljerad design, tillverkning (programimplementering) och testning, med målet att undvika återgång så mycket som möjligt (vanligtvis kallat vattenfallsmodellen). Men i verkligheten händer det ofta att det uppstår återgång i processen på grund av vissa omständigheter, som att det finns brister i föregående process.

Hur ska vi tänka om vi inte hinner med leveranstiden i sådana fall? Genom att tolka tidigare prejudikat verkar det som att slutsatsen varierar beroende på när det extra arbetet uppstod.

Om det extra arbetet var före klargörandet av specifikationerna, som extern design

Det tidigare nämnda prejudikatet indikerar att det inte nödvändigtvis är ett brott mot samarbetsplikten att begära ytterligare utveckling från användaren under grundläggande design (före programimplementeringsfasen).

Det är naturligt för användaren att ställa olika krav på systemet som ska byggas under grundläggande designarbete, och dessutom, för användaren som saknar teknisk kunskap, är det svårt att korrekt bedöma om sådana krav kräver extra avgifter eller förlängning av leveranstiden, eller om de kommer att störa arbetsprocessen. Därför kan vi inte säga att användaren borde ha avhållit sig från att ställa krav som skulle medföra extra avgifter eller förlängning av leveranstiden. Snarare, om användaren ställde krav som skulle kräva extra avgifter eller förlängning av leveranstiden, borde leverantören, som har projektledningsplikten, ha informerat användaren om detta och begärt diskussioner om att dra tillbaka kraven eller förlänga leveranstiden, så att utvecklingsarbetet inte störs.

Tokyo District Court, March 10, 2004 (Heisei 16)

I detta domslut bekräftades att användaren har vissa samarbetsplikter, men det påpekades också att användaren inte nödvändigtvis är en expert på systemutveckling. Med andra ord, eftersom användaren som beställer inte är en expert på systemutveckling, är det inte konstigt att de kommer med olika beställningar i små portioner tills innehållet i systemet som ska utvecklas blir klart (de kanske inte ens är vana vid att beställa), och det är orimligt att förvänta sig att de själva ska märka om innehållet i deras beställning kräver en översyn av leveranstiden och så vidare.

Emellertid, den skyldighet som åläggs leverantören här är i grunden att anstränga sig för att kommunicera, till exempel att begära en förlängning av leveranstiden (eller, om leveranstiden inte kan ändras, att föreslå att det extra kravet tas bort). Därför bör vi vara medvetna om att det inte nödvändigtvis innebär att leverantören är skyldig att acceptera alla användarens krav och leverera på ursprungligt datum.

Om det extra arbetet var efter att specifikationerna för tillverkning eller testfasen hade fastställts

Om vi vänder på innehållet i ovanstående dom kan vi i viss mån förutse vilken slutsats som skulle ha dragits om det var ytterligare utveckling efter att specifikationerna hade fastställts. I det fallet skulle det vara svårare att få igenom sådana krav. Visst, oavsett om det är före eller efter att specifikationerna har fastställts, förändras inte det faktum att det finns en stor skillnad i förståelsen för utvecklingsarbetet mellan användaren och leverantören.

Men att ändra eller lägga till beställningsinnehåll efter att specifikationerna har fastställts innebär en hög sannolikhet för att tvinga fram omarbetning. Det är ofta svårt att försvara förseningar som uppstår i sådana fall med argumentet att “det är naturligt för kunden att ha olika krav”. Dessutom, om det finns många specifikationsändringar och tillägg av funktioner efteråt, uppstår frågan om det inte fanns något brott mot samarbetsplikten från användarens sida redan i de tidigare faserna av grundläggande design och så vidare, som borde ha varit klara innan.

Med tanke på dessa punkter, är det inte realistiskt att betrakta förseningar i leveranstiden orsakade av specifikationsändringar som gjordes efter att specifikationerna en gång hade fastställts, som leverantörens ansvar. Det är rimligt att tolka det tidigare nämnda domslutet som att det också har denna innebörd.

Dessutom tenderar sådana bedömningar att göras med bevis som inte bara kontrakt, utan också mötesprotokoll som är anpassade till framstegen i systemutvecklingen. Jag har förklarat detaljerna om mötesprotokoll i följande artikel.

Relaterad artikel: Hur man behåller mötesprotokoll i systemutveckling ur ett juridiskt perspektiv[ja]

Sammanfattning: Det är viktigt att inte glömma att kravspecifikationen är en process på användarens sida

Kravspecifikationen är en möjlighet för leverantören att visa sin skicklighet, men det är viktigt att komma ihåg att det i grunden är en process på användarens sida. Eftersom det är ett system som används inom företaget, även om det skapas med hjälp av externa experter, bör det förutsättas att företagets styrning sträcker sig till det relevanta området enligt lag.

Om användarsidan inte samarbetar i utvecklingsprocessen, bör man först och främst vara medveten om att det finns en stor möjlighet att domstolen kommer att ha en sträng synpunkt även på användarsidan, även om projektet skulle gå upp i lågor.