Hvad er leverandørens supportforpligtelser efter afslutningen af systemudviklingen?

Det er almindeligt kendt i systemudvikling, at systemudviklingsspecialister, også kendt som leverandører, har en “projektledelsesforpligtelse”. Men der er også en lignende, men forskellig koncept i loven, kaldet “supportforpligtelse”. I denne artikel vil vi forklare denne “supportforpligtelse”, med henvisning til tidligere retssager og lignende.

Hvad er supportforpligtelsen?

En oversigt over supportforpligtelsen

Når vi taler om forpligtelser, som en leverandør har over for en bruger, er projektledelsesforpligtelsen en af de mest fremtrædende. Dette er et koncept, der er blevet etableret gennem gentagne henvisninger i tidligere retssager, og det opsummerer de forpligtelser, som leverandøren har over for et helt projekt som en ekspert inden for systemudvikling.

https://monolith.law/corporate/project-management-duties[ja]

Projektledelsesforpligtelsen er meget kendt som et juridisk udtryk inden for systemudvikling, og der er ingen tvivl om, at det er en af de primære forpligtelser, som leverandøren påtager sig. Men nogle retssager har anerkendt eksistensen af en anden forpligtelse, kaldet “supportforpligtelsen”, som er forskellig fra projektledelsesforpligtelsen.

Supportforpligtelsen bliver et problem i forhold til driftsstøtte til brugeren

Så hvad er supportforpligtelsen? Og hvorfor kaldes det noget andet end projektledelsesforpligtelsen? Supportforpligtelsen bliver normalt et problem efter afslutningen af systemudviklingen. Et systemudviklingsprojekt er, i sin grundlæggende tankegang, afsluttet, når det system, der skal skabes, er færdigt. Det vil sige, at det starter med at klargøre, hvad det system, der skal skabes, er (= kravspecifikation), og slutter med at bekræfte, om det faktisk er blevet skabt (= test eller accept). Dette er hvad et systemudviklingsprojekt er. For øvrigt, med hensyn til acceptprocessen, som har en vigtig betydning som “afslutningen af et systemudviklingsprojekt”, behandler vi de juridiske problemer, der ofte opstår på dette tidspunkt, i detaljer i følgende artikel.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Men selvom et systemudviklingsprojekt er forstået som selve udviklingsprocessen for at skabe et nyt system, er det en selvfølge, at det udviklede system vil blive brugt i forretningen efterfølgende. Med andre ord, det kan være urimeligt at sige, at “så længe vi kun er ansvarlige for udviklingsarbejdet, er det nok bare at skabe det”, uden at tage højde for, hvordan systemet skal bruges efter det er blevet udviklet. Med dette i tankerne, er det blevet et problem i tidligere retssager, om det er muligt at pålægge leverandøren, der er ansvarlig for systemudviklingen, en vis grad af driftsstøtteforpligtelse. Det vil sige, det er et spørgsmål om, hvorvidt vi bør betragte, at leverandørens forpligtelser i en systemudviklingskontrakt også inkluderer forpligtelser relateret til driftsstøtte efter udviklingen. Da driftsstøtte ikke er en del af selve udviklingsprocessen, tror vi, at udtrykket “supportforpligtelse” er blevet brugt for at skelne det fra projektledelsesforpligtelsen.

Hvad er retssager, hvor supportforpligtelsen er blevet et problem?

Et eksempel, hvor brugerens forretningsdrift blev hindret på systemteststadiet

I den dom, der citeres nedenfor, kunne brugeren ikke udnytte systemet som oprindeligt forventet under systemtesten før systemets drift, hvilket resulterede i, at brugeren opgav at sætte systemet i drift. Dette var et problem ved brugerens driftsstart, og spørgsmålet var, hvordan man kunne begrundet leverandørens ansvar ud fra den kontrakt, der var indgået på forhånd for systemudvikling. Konklusionen var, at brugerens krav om erstatning for skade blev anerkendt, og “overtrædelse af supportforpligtelsen” blev påpeget som grundlaget for dette.

I. Overtrædelse af supportforpligtelsen
(A) Den repræsentative for sagsøgeren anmodede sagsøgte den 14. juli i Heisei 9 (1997), om “ikke kun at lave systemet, men også at tage sig af det indtil det fungerer ordentligt.“, “Vi er amatører, så vi betaler en høj pris, så vi vil gerne have, at det kan bruges indtil det sidste.“. I respons herpå forklarede sagsøgte, at det var muligt at opbygge et system, der kunne opfylde sagsøgerens implementeringsmål, og lovede at yde support indtil systemet fungerede ordentligt. Dette resulterede i en aftale mellem sagsøgeren og sagsøgte om, at sagsøgte ville yde support indtil sagsøgeren kunne bruge systemet ordentligt.
Det er klart, at sagsøgte har en supportforpligtelse over for sagsøgeren, da der er opkrævet et beløb på 1.726.000 for “pakkeimplementeringsstøtte” som en del af kontraktens pris, og i estimatet er der angivet en “gratis vedligeholdelse i seks måneder efter implementering” under månedlig vedligeholdelsesgebyr, og det er bekræftet i et dokument med titlen “Om fremtidig SE-support (internt mødemateriale)” at SE-support kan modtages for “oprettelse af implementeringsprocedure (plan)” og “data/ driftsverifikationsarbejde” for friske ordrer.

(B) Og den supportforpligtelse, som sagsøgte har over for sagsøgeren, indebærer konkret, at sagsøgte i det mindste indtil sagsøgeren når til hoveddriften af systemet, skal ① give passende rådgivning om driftsmetoden for systemet, ② håndtere problemer med systemet, der opstår under driftstesten, ③ forbedre systemet i overensstemmelse med resultaterne af driftstesten, og ④ udføre introduktionsuddannelse for operatørerne.
Men sagsøgte, selvom der var mange problemer under driftstesten, forsøgte ikke at tage problemet alvorligt og hævdede, at det var et spørgsmål om operatørernes dygtighed, og krævede kun omkostningerne til introduktionsuddannelse for operatørerne, og ydede ikke nogen passende support til sagsøgeren for at gå i retning af hoveddriften.

Dom afsagt af Hachioji afdeling af Tokyo District Court den 5. november i Heisei 15 (2003)

I denne dom optræder ordet “support” omkring 30 gange i hele dommen, inklusive indholdsfortegnelsen. Det kan ses, at brugerens stemme, der kræver passende støtte, er direkte angivet i dommen, og at konklusionen blev nået efter at have overvejet forløbet af sagen meget konkret med henblik på en retfærdig løsning. Desuden er de punkter, der bør bemærkes især i forståelsen af denne sag,

• Overtrædelsen af supportforpligtelsen behandles som “misligholdelse af forpligtelser”, og derfor blev erstatning for den skade, der opstod som et resultat, beordret
• Udtrykket “projektledelsesforpligtelse” bruges ikke en eneste gang i hele dommen

Dette viser en holdning til at behandle det som en kontraktlig forpligtelse, der er indeholdt i kontrakten for systemudvikling, selvom det er et andet koncept end projektledelse.

Hvordan skal vi forstå naturen af supportforpligtelsen?

Supportforpligtelsen er endnu ikke et klart koncept

Den tidligere nævnte retssag viser i bund og grund, at leverandøren, der har udviklet systemet, også skal yde den nødvendige support for at brugeren kan starte driften. Men supportforpligtelsen er ikke så rig på præcedens som projektledelsesforpligtelsen, og der er ikke mange spor til at forstå dens virkelighed. Især indeholder termen “support” selv problemet med, at det ikke er klart, hvad der konkret skal gøres.

Supportforpligtelsen er ikke ubegrænset

Desuden har den ovennævnte dom, der anerkendte leverandørens brud på supportforpligtelsen, også vist et meget vigtigt punkt.

Defendanten forstås at have en forpligtelse til at yde en vis support, der er nødvendig for sagsøgeren til at drive det system, der er bygget og leveret til sagsøgeren baseret på denne kontrakt. Men indholdet af dette kan ikke forstås som sagsøgeren hævder, at det er at yde al support gratis indtil sagsøgeren faktisk kan drive dette system, uden at begrænse perioden.

Dom afsagt af Hachioji afdeling af Tokyo District Court den 5. november 2003 (Heisei 15)

Det kan tænkes, at det påpeger, at der naturligvis er begrænsninger på, hvad der skal gøres som support for “drift”, hvis det primære arbejde, der er overtaget, er system “udvikling”. I denne dom er der flere karakteristiske punkter, såsom at citere brugerens stemme, der anmoder om support, at nævne indholdet af det oprindelige skøn, og at nævne tilstedeværelsen eller fraværet af en særlig aftale om at yde support. Med andre ord, det kan tænkes, at det var hensigten at være ret forsigtig med at anerkende overtrædelsen af forpligtelsen, idet man tager højde for, at hvis konceptet af supportforpligtelsen udvides ubegrænset, vil det pålægge en stor byrde på leverandørsiden.

Den faktiske situation med supportforpligtelsen bør overvejes sammen med brugerens samarbejdsforpligtelse

Historien indtil nu kan i bund og grund siges at være en diskussion om “hvordan brugeren og leverandøren skal dele arbejdsbyrden i de indledende faser af drift i systemudvikling”. Det indeholder bestemt det lidt komplekse problem med, hvor meget juridisk forpligtelse leverandøren skal påtage sig ved driftsstart fra kontrakten om “udvikling”. Samtidig er det uundgåeligt at sige, at der er en stærk tendens til at kræve en vurdering baseret på individuelle omstændigheder.

Men det kan tænkes, at forståelsen af, hvad den faktiske situation med supportforpligtelsen, som leverandøren skal påtage sig, er, vil blive mere sikker ved at forstå brugerens samarbejdsforpligtelse.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Initiativer til at forbedre arbejdet med et nyt system er i første omgang et fælles arbejde mellem leverandøren, der er en teknisk ekspert, og brugeren, der har virksomhedskendskab i virksomheden. Derfor kan det tænkes, at der ofte er tilfælde, hvor omfanget af det, der kaldes supportforpligtelsen, naturligt vil blive bestemt ved at gøre det klart, hvad brugeren skal løse med egen hjælp som en del af “udførelsen af samarbejdsforpligtelsen”.

Opsummering

I denne artikel har vi gennemgået grundlæggende aspekter af projektledelse, og har forsøgt at organisere begrebet ‘supportforpligtelse’, som kan betragtes som en afledning af projektledelse. Selvom der stadig er mange uklarheder omkring begrebet supportforpligtelse, mener vi, at det er vigtigt at forstå grundlæggende koncepter som ‘projektledelsesforpligtelse’ og ‘samarbejdsforpligtelse’ for at kunne forstå det.