Vad är supportskyldigheten som leverantören bär efter systemutvecklingen är avslutad?

Det är allmänt känt att systemutvecklingsleverantörer, eller “leverantörer”, bär ett “projektledningsansvar” inom systemutveckling. Men det finns också ett liknande men distinkt koncept i lag, kallat “supportskyldighet”. I denna artikel kommer vi att förklara denna “supportskyldighet”, med hänsyn till tidigare rättsfall och liknande.

Vad är supportskyldighet?

Översikt över supportskyldighet

När vi talar om skyldigheter som en leverantör har gentemot en användare, är projektledningsskyldighet en av de mest framstående. Detta är ett koncept som har etablerats genom upprepade omnämnanden i tidigare rättsfall och sammanfattar de skyldigheter som leverantören, som en expert på systemutveckling, har gentemot ett projekt.

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

Projektledningsskyldighet är en mycket känd juridisk term inom systemutveckling, och det finns ingen tvekan om att det är en av de huvudsakliga skyldigheterna som leverantören tar på sig. Men i vissa rättsfall erkänns existensen av en skyldighet som skiljer sig från projektledningsskyldigheten, kallad “supportskyldighet”.

Supportskyldighet blir ett problem i driftsstöd för användare

Så vad är supportskyldighet? Och varför kallas det med ett annat namn än projektledningsskyldighet? Supportskyldighet blir vanligtvis ett problem efter att systemutvecklingen är klar. Ett systemutvecklingsprojekt, eftersom det är ett “utvecklings”-projekt, avslutas i princip när det system som ska skapas är klart. Det vill säga, ett systemutvecklingsprojekt börjar med att klargöra vad systemet ska vara (= kravspecifikation) och slutar med att bekräfta om det faktiskt har skapats (= testning eller acceptans). För övrigt, med tanke på att acceptansfasen har en viktig betydelse som “slutet på systemutvecklingsprojektet”, behandlas de juridiska problem som ofta uppstår vid detta skede i detalj i följande artikel.

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

Men även om ett systemutvecklingsprojekt förstås som själva utvecklingsprocessen för att skapa ett nytt system, är det självklart att det utvecklade systemet kommer att användas i verksamheten därefter. Med andra ord, om man ignorerar hur systemet ska användas efter att det har utvecklats och säger att “så länge jag bara skapar det, eftersom jag bara ansvarar för utvecklingsarbetet”, kan det leda till stora orimligheter. Med detta i åtanke har det i tidigare rättsfall varit en fråga om det är möjligt att pålägga leverantören, som ansvarar för systemutvecklingen, en viss skyldighet att stödja driften. Det vill säga, frågan är om man bör anse att leverantörens skyldigheter i ett systemutvecklingsavtal inkluderar skyldigheter relaterade till driftsstöd efter utvecklingen. Eftersom driftsstöd inte är en del av själva utvecklingsprocessen, tror man att termen “supportskyldighet” har använts för att skilja den från projektledningsskyldighet.

Domstolsfall där supportskyldighet blev ett problem

Ett fall där användarens verksamhet stördes på systemteststadiet

I det domslut som citeras nedan kunde användaren inte utnyttja systemet som ursprungligen förväntat under systemtestet som utfördes före systemets driftstart. Som ett resultat gav användaren upp att sätta systemet i drift. I detta fall var problemet hur man skulle motivera leverantörens ansvar utifrån kontraktet för systemutveckling som ingåtts i förväg, trots att det var ett problem vid användarens driftstart. Slutsatsen blev att användarens krav på skadestånd godkändes, och “brott mot supportskyldigheten” pekades ut som grund.

I. Brott mot supportskyldigheten
(A) Den 14 juli 1997 (Heisei 9) bad företrädaren för käranden svaranden att “inte bara skapa systemet, utan också se till att det fungerar ordentligt till slut.” och “Vi är amatörer, så vi betalar mycket pengar, så vi vill att du ser till att vi kan använda det till slut.“. Som svar på detta förklarade svaranden att det var möjligt att bygga ett system som kunde uppnå kärandens införandeändamål och lovade att ge support tills det fungerade ordentligt. Detta ledde till en överenskommelse mellan käranden och svaranden att svaranden skulle ge support tills käranden kunde använda systemet ordentligt.
Det är tydligt att svaranden har en supportskyldighet mot käranden, eftersom svaranden har bokfört en kostnad på 1 726 000 yen för “paketinföringsstöd” som kontraktspriset för detta kontrakt, och i offerten står det att det finns “sex månaders gratis underhåll” för månadsunderhållsavgiften, och i ett dokument med titeln “Om framtida SE-support (internt mötesmaterial)” bekräftas det att SE-support kan erhållas för “skapande av införingsprocedur (plan)” och “data/ driftsverifieringsarbete” för färskvarubeställning.

(B) Och den supportskyldighet som svaranden har mot käranden innebär konkret att svaranden åtminstone fram till käranden har satt systemet i full drift, ska ① ge lämplig rådgivning till käranden om hur man driver systemet, ② hantera problem som uppstår i systemet under driftstestet, ③ förbättra systemet baserat på resultaten av driftstestet, ④ ge införingsutbildning till operatörerna.
Men trots att det uppstod många problem under driftstestet, tog svaranden inte detta på allvar och hävdade att det var ett problem med operatörernas skicklighet, och begärde bara kostnader för införingsutbildning för operatörerna, och gav inte käranden något lämpligt stöd för att gå mot full drift.

Dom av Hachioji-avdelningen vid Tokyo District Court den 5 november 2003 (Heisei 15)

I detta domslut, inklusive innehållsförteckningen, dyker ordet “support” upp cirka 30 gånger i hela domslutet. Användarens röster som efterfrågar lämpligt stöd återges direkt i domslutet, vilket tyder på att det var en slutsats som strävade efter en rättvis lösning medan man noggrant övervägde händelseförloppet. En annan punkt som bör uppmärksammas när det gäller förståelsen av detta fall är att,

• Brott mot supportskyldigheten behandlas som “kontraktsbrott”, vilket ledde till att skadestånd för den resulterande skadan beordrades.
• Termen “projektledningsskyldighet” används inte en enda gång i hela domslutet.

Detta visar en inställning att behandla det som ett koncept skilt från projektledning, men ändå behandla det som en kontraktsmässig skyldighet som systemutvecklingskontraktet innehåller.

Hur bör vi tolka karaktären av supportskyldigheten?

Supportskyldigheten är ännu inte ett klart koncept

Den tidigare nämnda rättsfallet indikerar att leverantören som har utvecklat systemet också bör ge det nödvändiga stödet för att användaren ska kunna starta driften. Men supportskyldigheten har inte lika mycket rättspraxis och andra resurser som projektledningsskyldigheten, och det finns inte så många ledtrådar för att förstå dess verkliga natur. Framför allt innehåller termen “support” i sig problemet att det inte är klart exakt vad som ska göras.

Supportskyldigheten erkänns inte obegränsat

Dessutom har domen som erkände leverantörens brott mot supportskyldigheten också visat en mycket viktig punkt.

Defendanten tolkas som att ha en skyldighet att ge ett visst stöd som är nödvändigt för att käranden ska kunna driva systemet som byggts och levererats till käranden enligt detta kontrakt. Men dess innehåll tolkas inte som att vara som käranden hävdar, att ge all slags support gratis tills käranden faktiskt kan driva detta system, utan tidsbegränsning.

Tokyo District Court Hachioji Branch, November 5, Heisei 15 (2003)

Om huvuduppgiften som har tagits på sig är systemutveckling, kan det antas att det också finns vissa begränsningar för vad som bör göras som support för efterföljande drift. I denna dom finns det flera särdrag, såsom att citera användarens röst som begär stöd i domstolsbeslutet, att hänvisa till innehållet i den preliminära uppskattningen, och att nämna förekomsten av särskilda avtal om att ge support. Med andra ord, med tanke på att om konceptet med supportskyldighet utvidgas obegränsat skulle det lägga en stor börda på leverantören, kan det antas att det var avsiktligt att vara ganska försiktig med att erkänna brott mot skyldigheten.

Verkligheten av supportskyldigheten bör övervägas tillsammans med användarens samarbetsplikt

Sammanfattningsvis kan det sägas att diskussionen hittills har handlat om “hur användaren och leverantören ska dela arbetsbelastningen i de tidiga stadierna av drift i systemutveckling”. Det innehåller säkert något komplicerade frågor om hur mycket juridisk skyldighet leverantören har vid driftstart från kontraktet om “utveckling”. Samtidigt kan vi inte förneka att det finns en stark tendens att kräva bedömningar baserade på individuella omständigheter.

Men, det kan antas att förståelsen av vad som är kärnan i supportskyldigheten som leverantören bär blir mer säker genom att förstå samarbetsplikten som användaren bär.

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

Från början har ansträngningarna att förbättra verksamheten med ett nytt system aspekten av att vara ett gemensamt arbete mellan leverantören, som är en teknisk expert, och användaren, som har intern affärskunskap. Därför, när det gäller denna supportskyldighet, genom att klargöra vad användaren bör lösa genom egna ansträngningar som en del av “uppfyllandet av samarbetsplikten”, kan det ofta vara fallet att dess omfattning naturligt bestäms.

Sammanfattning

I denna artikel har vi gått igenom grunderna i projektledning och försökt att organisera begreppet “stödskyldighet”, som kan ses som en derivat av projektledning. Även om det fortfarande finns många oklarheter kring begreppet stödskyldighet, tror vi att det är grundläggande frågor som “projektledningsskyldighet” och “samarbetsskyldighet” som blir viktiga för att förstå det.